Re: Support articulations, slurs and breaths in MIDI (issue 26470047)
David Kastrup wrote: So it would be extra-velocity. That makes it sound like it's added to velocity instead of multiplied — but actually it should be added, because it gives a more consistent effect across dynamics. Multiplying a quiet note's velocity by 1.2 gives hardly any accent, but adding 20 sounds about the same at \pp and \ff. I'll change it. Ian Hulin wrote: Also, if your aim is to implement the articulate.ly audio effects without having to use articulate.ly work-round method of using a parallel \score block that's a good aim, too. That's the idea. the next goal for this sub-project may be to get the audio playback to honour the \repeat structures by translating the volta and tremolo flavours to unfold. I want this too, but apparently it was discussed previously, and some users don't want voltas automatically unfolded, because they don't want to hear them twice when proofreading. Another performer-type issue - very definitely separate from this patch - is transposed audio output. Best to note the interaction of the audio output and the \transpose and \transposition commands as a TODO - the issue is does Lily apply pitch-bends to effect audio transposition to implement respect a \transposition command and how does this play nicely when \transpose is used for the printed output? Audio_note just uses Pitch::transposed; it doesn't do anything special about \transpose. IIUC the only problem with their interaction is that \transpose mistakenly transposes \transposition. [on overlapping notes in slurs] Are there any negative results for percussive and plucked instruments when using this approach? For undamped instruments like harp and most drums, no — these instruments generally ignore the note-off event, so it doesn't matter when it comes. For guitar-like instruments, the result is not a significant improvement, because the notes are still replucked instead of just fingered. I don't think MIDI can do pull-offs without either portamento-mode or pitch-bend abuse. Is co-existence and inter-operation with articulate.ly an overall goal for this set of patches? Not specifically, but it would be annoying if it broke articulate.ly (by e.g. shortening staccatos twice), since so many people use it. Or have the hook scale up the durations of the notes you return by a factor you tune via a property for all fermatae? Doing fermatas by changing the durations would require delaying all later notes. This isn't supported yet, but might not be terribly hard to add. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Support articulations, slurs and breaths in MIDI (issue 26470047)
On 2013/11/24 15:11:38, Devon Schudy wrote: David Kastrup wrote: the next goal for this sub-project may be to get the audio playback to honour the \repeat structures by translating the volta and tremolo flavours to unfold. I want this too, but apparently it was discussed previously, and some users don't want voltas automatically unfolded, because they don't want to hear them twice when proofreading. Perhaps do it conditionally based on some context property? Audio_note just uses Pitch::transposed; it doesn't do anything special about \transpose. IIUC the only problem with their interaction is that \transpose mistakenly transposes \transposition. Oh no, we fixed that in issue 754 in February, 2.17.13. Or have the hook scale up the durations of the notes you return by a factor you tune via a property for all fermatae? Doing fermatas by changing the durations would require delaying all later notes. This isn't supported yet, but might not be terribly hard to add. A factor is the wrong thing to do as then polyphonic passages will get out of sync when the last note at the fermata has a different length in different voices. I think that using one beat or a fraction of a measure should likely be used. https://codereview.appspot.com/26470047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Support articulations, slurs and breaths in MIDI (issue 26470047)
2013/11/24 d...@gnu.org: On 2013/11/24 15:11:38, Devon Schudy wrote: David Kastrup wrote: the next goal for this sub-project may be to get the audio playback to honour the \repeat structures by translating the volta and tremolo flavours to unfold. I want this too, but apparently it was discussed previously, and some users don't want voltas automatically unfolded, because they don't want to hear them twice when proofreading. Perhaps do it conditionally based on some context property? I would like that! I'm one of the users who'd like the music to be automatically unfolded (in fact, i don't understand why would someone not want to have at least tremolo repeats unfolded). Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reasoning behind convert-ly rule for stable update?
Hi, I've postponed doing the big convert-ly update beyond 2.18 version numbers since it's bad for merge conflict resolution (there are literally thousands of files affected). Does anybody know _why_ convert-ly updates at least to the last stable version number even if nothing else has been changed? For one thing, it might be a question of efficiency, granted. Going through every conversion rule from history's end to today repeatedly is likely to be expensive. But for another, it loses significant information. Is there some way we can retain this information? Like adding a comment % convert-ly version 2.17.28 or something, and when convert-ly sees this comment, it only deals with that until it does encounter an actually changing conversion? Or make \version accept a range? \version 2.16.0 - 2.17.28 Then LilyPond just needs to check the first number, and convert-ly just deals with the second number as long as it does not need to add another conversion. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reasoning behind convert-ly rule for stable update?
Does anybody know _why_ convert-ly updates at least to the last stable version number even if nothing else has been changed? Looks like a bad idea, indeed. Or make \version accept a range? \version 2.16.0 - 2.17.28 Then LilyPond just needs to check the first number, and convert-ly just deals with the second number as long as it does not need to add another conversion. I don't like this. \version should stay unmodified if nothing gets changed, and I favor a change in convert-ly accordingly. However, I can imagine that, completely independent from convert-ly, another script adds something like % tested with version 2.17.95 and this comment gets updated whenever we feel it is the right thing to do. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reasoning behind convert-ly rule for stable update?
Werner LEMBERG w...@gnu.org writes: Does anybody know _why_ convert-ly updates at least to the last stable version number even if nothing else has been changed? Looks like a bad idea, indeed. Or make \version accept a range? \version 2.16.0 - 2.17.28 Then LilyPond just needs to check the first number, and convert-ly just deals with the second number as long as it does not need to add another conversion. I don't like this. \version should stay unmodified if nothing gets changed, and I favor a change in convert-ly accordingly. However, I can imagine that, completely independent from convert-ly, another script adds something like % tested with version 2.17.95 That's nice and all, but irrelevant to the problem of reducing the amount of work convert-ly has to do on unchanged files. Currently convert-ly checks about 30 rules or so at the end of an unstable release cycle. This would easily grow into several hundreds if we don't leave any indication what kind of rules _have_ already been applied without effect. I'm not sure that's actually a problem: at the current point of time, by far the bulk of update-with-convert-ly.sh's runtime is spent running make all. And it's probably also ok to restart with a clean state for LilyPond's core documentation files, and its code files. But for the LSR snippets and the example files and the regression tests, it seems somewhat excessive to update. Now the idea of add a comment is not really useful when the aim is to avoid unnecessary merge conflicts. If we don't want merge conflicts from the main \version, we don't want them from a comment either. Taking a look at our current Documentation/snippets, we have the following statistics: git grep -h '\\version' Documentation/snippets|sort -n|uniq -c 140 \version 2.16.0 26 \version 2.17.11 2 \version 2.17.13 2 \version 2.17.14 9 \version 2.17.15 5 \version 2.17.18 2 \version 2.17.23 4 \version 2.17.24 2 \version 2.17.25 8 \version 2.17.27 4 \version 2.17.28 1 \version 2.17.29 34 \version 2.17.30 2 \version 2.17.5 162 \version 2.17.6 4 \version 2.17.7 So in this cycle, only about a third of the files stayed at 2.16.0. So the average conversion chain length will not actually reach even two stable versions. Of course, it is not random which files get hit: the really short and simple ones are more likely to stick around unchanged for longer. But those are also less costly. The regression tests are quite selective: here we have 718 of 1185 that are at 2.16.0, so about 60%. But that still does not make for much more than a mean delay of 3 stable versions before update. So I lean towards just ripping the respective code out from convert-ly. I _think_ we have options that allow to simulate the update to a particular version if one really wants to. Of course, this will likely make the LSR import slower, too. But I think it can't hold a candle towards the is this safe? checks, either. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reasoning behind convert-ly rule for stable update?
David Kastrup d...@gnu.org writes: That's nice and all, but irrelevant to the problem of reducing the amount of work convert-ly has to do on unchanged files. Oh phooey. Of course update-with-convert-ly can generally start with the last stable safely. Nothing in the tree will be older than that. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reasoning behind convert-ly rule for stable update?
David Kastrup d...@gnu.org writes: David Kastrup d...@gnu.org writes: That's nice and all, but irrelevant to the problem of reducing the amount of work convert-ly has to do on unchanged files. Oh phooey. Of course update-with-convert-ly can generally start with the last stable safely. Nothing in the tree will be older than that. Ok, here is what _might_ have been the idea from the code. Suppose that I have a file for version 2.15.5 and I run convert-ly 2.17.8 without options on the file, and there is one conversion applied at 2.15.11. Then instead of claiming the file to be 2.15.11, stuff gets rounded up and 2.16.0 is claimed instead, just losing a bit of history within unstable versions. That would make some sense. It would not make things significantly more efficient, but it would throw away old unstable version history which is not all that interesting. But the code currently does not appear to work this way: it seems to promote even an unchanged 2.16.0 to 2.18.0. And besides, updates when there are _no_ changes should be skipped in either case. I'll try to see whether I figure something out in that direction. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reasoning behind convert-ly rule for stable update?
2013/11/24 David Kastrup d...@gnu.org: Ok, here is what _might_ have been the idea from the code. Suppose that I have a file for version 2.15.5 and I run convert-ly 2.17.8 without options on the file, and there is one conversion applied at 2.15.11. Then instead of claiming the file to be 2.15.11, stuff gets rounded up and 2.16.0 is claimed instead, just losing a bit of history within unstable versions. That would make some sense. It would not make things significantly more efficient, but it would throw away old unstable version history which is not all that interesting. But the code currently does not appear to work this way: it seems to promote even an unchanged 2.16.0 to 2.18.0. And besides, updates when there are _no_ changes should be skipped in either case. I'll try to see whether I figure something out in that direction. +1 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reasoning behind convert-ly rule for stable update?
On Sun, Nov 24, 2013 at 06:12:16PM +0100, David Kastrup wrote: Does anybody know _why_ convert-ly updates at least to the last stable version number even if nothing else has been changed? Yes, because it's confusing for some users if they've downloaded the latest and greatest lilypond 2.18.0, run convert-ly, and see that their files are 2.17.37. If you check the git history on convert-ly or convert-rules, then check the mailing list archives from a few days before then, you'll see the discussion. Or this might even be in the issue tracker. Also, when dealing with large collections of files, it's reassuring that the files really are current as-of 2.x.0. I mean, if I see input/regression/foo.ly being 2.13.5, does that mean that people forgot to run convert-ly, or does it mean that it really has no syntax changes since then? But for another, it loses significant information. Is there some way we can retain this information? I don't think that's useful info, but I suppose that there's little harm in adding an option to convert-ly which writes a comment with the previous revision. It shouldn't be the default behaviour, though. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reasoning behind convert-ly rule for stable update?
Graham Percival gra...@percival-music.ca writes: On Sun, Nov 24, 2013 at 06:12:16PM +0100, David Kastrup wrote: Does anybody know _why_ convert-ly updates at least to the last stable version number even if nothing else has been changed? Yes, because it's confusing for some users if they've downloaded the latest and greatest lilypond 2.18.0, run convert-ly, and see that their files are 2.17.37. Well, they can use -c then. If you check the git history on convert-ly or convert-rules, then check the mailing list archives from a few days before then, you'll see the discussion. Or this might even be in the issue tracker. Also, when dealing with large collections of files, it's reassuring that the files really are current as-of 2.x.0. I mean, if I see input/regression/foo.ly being 2.13.5, does that mean that people forgot to run convert-ly, or does it mean that it really has no syntax changes since then? If you want the former, use -c. If I see input/regression/foo.ly being 2.16.0, does that mean that people forgot to run convert-ly, or does it means that it really has no syntax changes since then? The most important thing is that if I see Documentation/snippet/some-file.ly, I can figure out whether it will run with 2.16.2 even when it is contained in 2.18.0. And then there are the merge conflicts from gratuitous changes. I'll take a look whether I can dig up the discussion. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reasoning behind convert-ly rule for stable update?
Graham Percival graham at percival-music.ca writes: On Sun, Nov 24, 2013 at 06:12:16PM +0100, David Kastrup wrote: Does anybody know _why_ convert-ly updates at least to the last stable version number even if nothing else has been changed? Yes, because it's confusing for some users if they've downloaded the latest and greatest lilypond 2.18.0, run convert-ly, and see that their files are 2.17.37. If users run convert-ly without the '-d' option, then the version string is updated to the last version considered by convert-ly, and if we have a dummy rule for 2.18.0 (like we have for stable releases since 1.6.0) that version will be 2.18.0 Also, when dealing with large collections of files, it's reassuring that the files really are current as-of 2.x.0. I mean, if I see input/regression/foo.ly being 2.13.5, does that mean that people forgot to run convert-ly, or does it mean that it really has no syntax changes since then? That argument seems to apply to the snippets, reassuring users that they pulled a snippet that should work. For a regression test, if someone forgot to run convert-ly then it will either fail pass its test, or the conversion must not have been important. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Make convert-ly -d only ever update on changed files (issue 31830043)
I'm fine with this, but then we would probably want to run convert-ly without the '-d' option on Documentation/snippets, upon creation of version 2.18.0. Maybe there is a way to get the behavior of round-up-to stable version triggered by the (usually dummy) convert-ly rule for that version. I can only think of kludgy ways right now https://codereview.appspot.com/31830043/diff/1/scripts/convert-ly.py File scripts/convert-ly.py (left): https://codereview.appspot.com/31830043/diff/1/scripts/convert-ly.py#oldcode295 scripts/convert-ly.py:295: # check the y in x.y.z (minor version number) This did cause me confusion recently, while preparing the keySignature name-change that I had postponed for the 2.19.x branch. I knew about the mechanism to update to a stable label using a dummy-rule mechanism in convertrules.py, but this hidden mechanism surprised me. Why, I thought, does it know about 2.18.0 when that version does not exist? https://codereview.appspot.com/31830043/diff/1/scripts/convert-ly.py File scripts/convert-ly.py (right): https://codereview.appspot.com/31830043/diff/1/scripts/convert-ly.py#newcode306 scripts/convert-ly.py:306: last = next_stable The old code was there so that the \version .. is updated for a new stable version http://codereview.appspot.com/2642041/#msg3 It looks like the new code does not perform this function. It takes some patience to understand what this does, either by reading the doc-string or the code, because it is a sophisticated behavior, and I do not understand its purpose or motivation. https://codereview.appspot.com/31830043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
anyone notice speed of 2.17.95 on Windows ?
LilyPond has always been a slower on Windows than under Linux, but I get worried if it is more than twice as slow. I would think the operating systems affect speed mostly through 1) the font server, 2) memory allocation, and 3) the Guile implementation. I timed one big score, Movement 1 of http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=1793 2.16.2 2.17.95 WinXP 2m 30s 5m 10s Fedora 1m 50s 1m 50s and do not like the 5m (although I remember version 2.12 taking 20 minutes for this movement) But the timing for another score http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=1320 comes out more evenly 2.16.2 2.17.95 WinXP 1m 15s 1m 30s Fedora 46s 39s Maybe the first example has some specific quirk, so I'll dig deeper. The big change of using skylines for placement around music does not cost much when there are no lyrics or other text placed against music. Has anyone else noticed a troublesome slowdown? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make convert-ly -d only ever update on changed files (issue 31830043)
Reviewers: Keith,
Message:
On 2013/11/25 06:37:35, Keith wrote:
I'm fine with this,
but then we would probably want to run convert-ly without the '-d'
option on
Documentation/snippets, upon creation of version 2.18.0.
Maybe there is a way to get the behavior of round-up-to stable
version
triggered by the (usually dummy) convert-ly rule for that version. I
can only
think of kludgy ways right now
The dummy convert-ly rule is actually dummy when used with -d: it is
not specially parsed or anything. The update is instead triggered by
the version number of the last checked rule. For that reason, a number
of issues with convert-ly rule for 2.19.0 have not been uploaded by me:
they contain thousands of gratuitous changes.
https://codereview.appspot.com/31830043/diff/1/scripts/convert-ly.py
File scripts/convert-ly.py (left):
https://codereview.appspot.com/31830043/diff/1/scripts/convert-ly.py#oldcode295
scripts/convert-ly.py:295: # check the y in x.y.z (minor version
number)
This did cause me confusion recently, while preparing the keySignature
name-change that I had postponed for the 2.19.x branch.
I knew about the mechanism to update to a stable label using a
dummy-rule
mechanism in convertrules.py, but this hidden mechanism surprised me.
Why, I
thought, does it know about 2.18.0 when that version does not exist?
Because that's the you have considered a rule beyond that.
https://codereview.appspot.com/31830043/diff/1/scripts/convert-ly.py
File scripts/convert-ly.py (right):
https://codereview.appspot.com/31830043/diff/1/scripts/convert-ly.py#newcode306
scripts/convert-ly.py:306: last = next_stable
The old code was there so that the \version .. is updated for a new
stable
version http://codereview.appspot.com/2642041/#msg3
It looks like the new code does not perform this function.
Yes, that's the intent.
It takes some patience to understand what this does, either by reading
the
doc-string or the code, because it is a sophisticated behavior, and I
do not
understand its purpose or motivation.
This basically comes into play only when importing stuff. Note that
stuff like the LSR runs on stable versions, and that's basically what
ordinary users have. In that case, _if_ a conversion happens, the
version number in the file will reflect a stable version, 2.12.0,
2.14.0, 2.16.0, 2.18.0: whatever is the oldest stable version left
unchanged by convert-ly.
Description:
Make convert-ly -d only ever update on changed files
Previously, it updated unconditionally whenever a new stable version
came out, leading to merge conflicts. When the final applied
conversion is to an unstable version and the following stable version
is not beyond the conversion target, the following stable version is
used.
Note that this rule does not make a factual difference for continuous
updates of a code base (the normal use case for
scripts/auxiliar/update-with-convert-ly.sh), but it makes a difference
for the conversion/import of code that may have fallen behind a lot
(like with the LSR import, or when converting archived files).
Please review this at https://codereview.appspot.com/31830043/
Affected files (+15, -11 lines):
M Documentation/usage/updating.itely
M scripts/convert-ly.py
Index: Documentation/usage/updating.itely
diff --git a/Documentation/usage/updating.itely
b/Documentation/usage/updating.itely
index
06a960ac8a866faff27da9fece4208a96d395a78..ad92a834e35db8307521379f9dc4bd9789e6ce09
100644
--- a/Documentation/usage/updating.itely
+++ b/Documentation/usage/updating.itely
@@ -151,8 +151,11 @@ The following options can be given:
@item -d, --diff-version-update
increase the @code{\version} string only if the file has actually
been changed. In that case, the version header will correspond to
-the version after the last actual change. Without that option,
-the version will reflect the last @emph{attempted} conversion.
+the version after the last actual change. An unstable version
+number will be rounded up to the next stable version number unless
+that would exceed the target version number. Without this option,
+the version will instead reflect the last @emph{attempted}
+conversion.
@item -e, --edit
Apply the conversions direct to the input file, modifying it
Index: scripts/convert-ly.py
diff --git a/scripts/convert-ly.py b/scripts/convert-ly.py
index
641d763713c979c06dfe0621e19959303765403d..ede9d4a98b81ea7309288364603c2a767cdca00a
100644
--- a/scripts/convert-ly.py
+++ b/scripts/convert-ly.py
@@ -292,17 +292,18 @@ def do_one_file (infile_name):
# Note that last_change can be set even if the result is
# the same if two conversion rules cancelled out
if result == input:
-# check the y in x.y.z (minor version number)
-previous_stable = (last[0], 2*(last[1]/2), 0)
-if ((last[0:2] != from_version[0:2]) and
-(previous_stable from_version)):
-
