Re: Issue 2232: fix MIDI output of abutting (de)crescendi (issue 300300043 by nine.fierce.ball...@gmail.com)
Reviewers: ht,
Message:
On 2016/06/07 19:07:40, ht wrote:
Do I understand correctly that this change in effect automatically
replaces
every { ... CC ... DD ... } (where CC and DD can be either \< or \>,
with no
(de)crescendo events between them) with { ... CC ... \! DD ... }
That is my understanding.
With the patch I get an "Impossible or ambiguous (de)crescendo in
MIDI" warning
from this example, though
That probably falls under
https://sourceforge.net/p/testlilyissues/issues/4048/ .
Thanks for your review and the example.
Description:
Is it really this easy?
I checked the velocity of the output MIDI by inspecting the notes in
Aria Maestosa.
Please review this at https://codereview.appspot.com/300300043/
Affected files (+13, -2 lines):
A input/regression/midi/crescendo-abutting.ly
M lily/dynamic-performer.cc
Index: input/regression/midi/crescendo-abutting.ly
diff --git a/input/regression/midi/crescendo-abutting.ly
b/input/regression/midi/crescendo-abutting.ly
new file mode 100644
index
..78cc1a3caed24aa6a600734c830673d604ea9e41
--- /dev/null
+++ b/input/regression/midi/crescendo-abutting.ly
@@ -0,0 +1,10 @@
+\version "2.19.43"
+
+\header {
+ texidoc="One (de)crescendo ends as the next begins."
+}
+
+\score {
+ { c\< c\> c\! }
+ \midi {}
+}
Index: lily/dynamic-performer.cc
diff --git a/lily/dynamic-performer.cc b/lily/dynamic-performer.cc
index
567184412e97a83008144613a9b02e459189ced5..3f9b1a5fedee3660450dab41047d571ef24b324e
100644
--- a/lily/dynamic-performer.cc
+++ b/lily/dynamic-performer.cc
@@ -105,9 +105,10 @@ Dynamic_performer::equalize_volume (Real volume)
void
Dynamic_performer::process_music ()
{
- if (span_events_[STOP] || script_event_)
+ if (span_events_[START] || span_events_[STOP] || script_event_)
{
- // End of a dynamic spanner, or an explicit dynamic script event.
+ // End the previous spanner when a new one begins or at an explicit
stop
+ // or absolute dynamic.
finished_span_dynamic_ = span_dynamic_;
span_dynamic_ = 0;
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue 2232: fix MIDI output of abutting (de)crescendi (issue 300300043 by nine.fierce.ball...@gmail.com)
Do I understand correctly that this change in effect automatically
replaces every { ... CC ... DD ... } (where CC and DD can be either \<
or \>, with no (de)crescendo events between them) with { ... CC ... \!
DD ... }, which has worked "as expected" even before?
Making crescendos immediately followed by a descrescendo (or vice versa)
work without the need to use explicit \!'s is certainly convenient, so I
think this is a welcome change.
Actually, this change also seems to alter the MIDI rendering of
\version "2.19.43"
\score {
\new Staff \with {
midiMinimumVolume = 0.0
midiMaximumVolume = 1.0
} \new Voice \relative c' {
c8\\< c\< c c\< c c c\< c c c\sf
% 4343 43 43 43 43 43 71 99 127 (velocities
without patch)
% 4371 86 100 109 118 127 127 127 127 (velocities with
patch)
}
\midi { }
}
to make the velocity adjustment actually span more than the last segment
of notes between two dynamic events (I hadn't even noticed the old
behavior, which I find somewhat unexpected).
With the patch I get an "Impossible or ambiguous (de)crescendo in MIDI"
warning from this example, though, but I think this is only because of
hitting the maximum possible velocity already before the last note -
since I didn't use any explicit dynamic events in the example, LilyPond
just uses the default (volume range dependent) velocity increment for
each segment between two crescendo events. Anyway, this behavior is
still consistent with what one gets without the patch by replacing every
\< with \!\<, so I'd still say that the patch improves things even in
this case.
https://codereview.appspot.com/300300043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Integrate Type1 font embedding procedures (issue 293710043 by truer...@gmail.com)
LGTM. https://codereview.appspot.com/293710043/diff/1/lily/pfb-scheme.cc File lily/pfb-scheme.cc (right): https://codereview.appspot.com/293710043/diff/1/lily/pfb-scheme.cc#newcode13 lily/pfb-scheme.cc:13: " to PFA format. If the file is already in PFA format," Please two spaces after a full dot. https://codereview.appspot.com/293710043/diff/1/lily/pfb-scheme.cc#newcode35 lily/pfb-scheme.cc:35: /* The file is in PFA format. Pass through it. */ I think this should be `Pass it through.' https://codereview.appspot.com/293710043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Spare SSD anybody?
On Wednesday, 1 June 2016 12:36:02 BST David Kastrup wrote: > Alexander Kobel writes: > ... > > Sure, it would be nice to keep in mind. I'm not really sure what the > expected lifetime of the disk I have is. Maybe I just need to keep > making backups in sane intervals and otherwise am still fine. I had cause to look into this recently and came across the following. Executive summary: everything is fine now and new SSDs last forever. http://techreport.com/review/27909/the-ssd-endurance-experiment-theyre-all-dead It's on the internet so it must be true :) (I expect more authoritative tests are available). I'm using a hybrid 1TB in my laptop at the moment with no problems with Debian Stretch GNU/Linux as the only OS installed. These devices feature typically 8GB or so of flash with the majority of the storage being on the whirlydisk. What the flash gets used for is up to the drive. With no tweaking or setup, it appears to me to be much faster than the old 1TB drive (only whirly, no flash), which I replaced because of increasingly frequent heat-related failures after it been running for 4 hours or so. Nick/. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc still fails - problem with lilypond-book - was: Still cannot make doc
>>> So do we need any warnings or notes to be added to here: >>> >>> http://lilypond.org/doc/v2.19/Documentation/usage-big-page#advanced-command-line-options-for-lilypond >>> >>> and/or here: >>> >>> http://lilypond.org/doc/v2.19/Documentation/notation-big-page#entire-document-fonts >>> >>> ? >> In my humble opinion, >> both options `-dgs-load-fonts' and `-dgs-load-lily-fonts' >> should be deprecated. >> >> I think that should be noted as deprecated in the document. >> >> > Sorry to appear pendantic but I am having a hard time parsing that - > or perhaps you are using the wrong word? > > When you say 'should' be deprecated do you mean these commands 'are' > deprecated or that you 'would like them to be' deprecated because they > *do* work (except in this case) or are they not expected to work at > all properly. > > I just am concerned there might be users that have a genuine use-case > for this option and it still works for them even in the later > versions? > > Perhaps you can give some words (like you have done before) that might > be suitable for the warning/note and I, if needed, can make them more > succinct in the English doc? Sorry. My explanation was poor. I'd like "-dgs-load-fonts" and "-dgs-load-lily-fonts" to be deprecated. If I understand correctly, the both options use a ghostscript language extension ".loadfont". Ghostscript developers seem to want us to not use the ghostscript language extension. http://bugs.ghostscript.com/show_bug.cgi?id=696823 http://bugs.ghostscript.com/show_bug.cgi?id=696824 As they said, to "use the documented method for loading fonts", the both options can not be used. So I propose that the both options are not used. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc still fails - problem with lilypond-book - was: Still cannot make doc
Hosoda-san, On 07/06/16 13:54, Masamichi Hosoda wrote: So do we need any warnings or notes to be added to here: http://lilypond.org/doc/v2.19/Documentation/usage-big-page#advanced-command-line-options-for-lilypond and/or here: http://lilypond.org/doc/v2.19/Documentation/notation-big-page#entire-document-fonts ? In my humble opinion, both options `-dgs-load-fonts' and `-dgs-load-lily-fonts' should be deprecated. I think that should be noted as deprecated in the document. Sorry to appear pendantic but I am having a hard time parsing that - or perhaps you are using the wrong word? When you say 'should' be deprecated do you mean these commands 'are' deprecated or that you 'would like them to be' deprecated because they *do* work (except in this case) or are they not expected to work at all properly. I just am concerned there might be users that have a genuine use-case for this option and it still works for them even in the later versions? Perhaps you can give some words (like you have done before) that might be suitable for the warning/note and I, if needed, can make them more succinct in the English doc? James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc still fails - problem with lilypond-book - was: Still cannot make doc
>>> Any idea why this is so? Could you contact the gs people by filing >>> a bug report so that we get an explanation? >> >> If I understand correctly, there is four issues at least. [...] > > Thanks for your analysis. There is ghostscript developers reply. http://bugs.ghostscript.com/show_bug.cgi?id=696823 http://bugs.ghostscript.com/show_bug.cgi?id=696824 They seem to want us to not use ghostscript language extension. If I understand correctly, LilyPond option `-dgs-load-fonts' and `-dgs-load-lily-fonts' use the ghostscript language extension `.loadfont'. In my humble opinion, both options should be `deprecated'. I'm trying to remove them used in `make doc' and lilypond-book. https://sourceforge.net/p/testlilyissues/issues/4882/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc still fails - problem with lilypond-book - was: Still cannot make doc
> So do we need any warnings or notes to be added to here: > > http://lilypond.org/doc/v2.19/Documentation/usage-big-page#advanced-command-line-options-for-lilypond > > and/or here: > > http://lilypond.org/doc/v2.19/Documentation/notation-big-page#entire-document-fonts > > ? In my humble opinion, both options `-dgs-load-fonts' and `-dgs-load-lily-fonts' should be deprecated. I think that should be noted as deprecated in the document. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Spare SSD anybody?
Dr Nicholas Bailey writes: > On Wednesday, 1 June 2016 12:36:02 BST David Kastrup wrote: >> Alexander Kobel writes: >> ... >> >> Sure, it would be nice to keep in mind. I'm not really sure what the >> expected lifetime of the disk I have is. Maybe I just need to keep >> making backups in sane intervals and otherwise am still fine. > > I had cause to look into this recently and came across the following. > Executive summary: everything is fine now and new SSDs last forever. Well, I don't exactly have a new SSD... > http://techreport.com/review/27909/the-ssd-endurance-experiment-theyre-all-dead > > It's on the internet so it must be true :) (I expect more > authoritative tests are available). > > I'm using a hybrid 1TB in my laptop at the moment with no problems > with Debian Stretch GNU/Linux as the only OS installed. These devices > feature typically 8GB or so of flash with the majority of the storage > being on the whirlydisk. What the flash gets used for is up to the > drive. Well, I'll just stick with what I have until replacement is mandatory or convenient. And then I (or more likely the facts) can decide on the parameters... -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
