Re: Map voices to channels in MIDI output
Keith OHara schreef op vr 18-03-2011 om 21:30 [-0700]: The code seems to work, but requires great effort to understand. Good, yes alas. I was suggesting that, having decided what you want in the MIDI, you might simplify the design. That would be nice and I'm sure that it can be simplified quite a bit. The thing is, we won't know until some time after 2.14 if the current default (voice-track, instrument-channel) works well for everyone. The old 'staff default is fairly ok for listening, but messes up the voices. That's bad for anyone wanting to do some postprocesing with it. The new 'voice flavour seems to be unfit for listening purposes, but is by far the most convenient option for postprocessing. Do you thing anything should go in the NEWS file? Jan. -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
RFC: include and document articulate script
If I did it well, here is it: http://codereview.appspot.com/4277067 -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets the beam collision engraver to handle autobeams (issue4287061)
This is now fully functional. The only issue is that, for auto-beams, I don't have a good method yet for keeping note-heads that are part of the beam out of the covered grobs list. This is doable, though - I just have to think of the cleanest way. http://codereview.appspot.com/4287061/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
critical issues
Hey guys, I've been busy/distracted/sick for the past week, and I'll continue to be busy/distracted/sick for the next ten days. I'm also fed up with announcing a release candidate and then discovering that there's a known critical issue that wasn't on the tracker a day later. 1) if you're working on a Critical issue, could you add it to the tracker? directly? i.e. don't rely on the bug squad to add it for you? 2) if you suspect that there's a Critical issue, and you're either on the bug squad or have git push access, could you add it to the tracker? directly? and by suspect, I mean as in shoot first, ask questions later? like, don't wait until somebody has confirmed it, just dump it in there so that I don't make yet another false release candidate announcement? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Include and document the Articulate script by Peter Chubb. (issue4277067)
Looks generally good to me.
http://codereview.appspot.com/4277067/diff/1/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
http://codereview.appspot.com/4277067/diff/1/Documentation/notation/input.itely#newcode1690
Documentation/notation/input.itely:1690: more realistic MIDI output is
available by means of the Articulate
could the Articulate script be a @ref{} ?
http://codereview.appspot.com/4277067/diff/1/Documentation/notation/input.itely#newcode2307
Documentation/notation/input.itely:2307: @unnumberedsubsubsec Using the
Articulate script
IMO, the @unnumberedsubsubsec doesn't add anything. I suggest omitting
this line entirely.
If you really really want that line there for some reason, then please
add a @node right above it, to match the doc policy.
http://codereview.appspot.com/4277067/diff/1/Documentation/notation/input.itely#newcode2316
Documentation/notation/input.itely:2316: and in the @code{\score}
section do
I do not believe that you have to include the \unfoldRepeats section.
Could you just change this to:
To create a MIDI file with all repeats played, add this to your \score:
http://codereview.appspot.com/4277067/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
GUB darwin-x86::cross/gcc build error
Hello, I can't build darwin-x86::cross/gcc with GUB. The logfiles were too big, I have pastebinned them: config.log: http://www.nilsgey.de/config.log gcc.log (3.8 MB): http://www.nilsgey.de/gcc.log I hope you can help me. Greetings, Nils P.S. This is maybe a false path. I once updated to a newer GCC version to see what happens and the error messages are better there. I got: checking for the correct version of the gmp/mpfr/mpc libraries... no configure: error: Building GCC requires GMP 4.2+, MPFR 2.3.1+ and MPC 0.8.0+. I think GUB built all these. Or are, by any chance host list needed? And if yes 32bit or 64bit (I'm on 64bit) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: Doc: Added new option 'papersize' to Usage
http://codereview.appspot.com/4289057 Doc: Added new option 'papersize' to Usage Added note on how to use @lilypond[papersize=xx] as defined in scm/paper.scm --- Hope this is in the appropriate place. James ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: Added new option 'papersize' to Usage (issue4289057)
http://codereview.appspot.com/4289057/diff/1/Documentation/usage/lilypond-book.itely
File Documentation/usage/lilypond-book.itely (right):
http://codereview.appspot.com/4289057/diff/1/Documentation/usage/lilypond-book.itely#newcode607
Documentation/usage/lilypond-book.itely:607: @code{'landscape} can also
be used.
oh neat -- if you want a8 landscape, do you put two papersize? or is it
a8landscape ? or a8 landscape ?
http://codereview.appspot.com/4289057/diff/1/Documentation/usage/lilypond-book.itely#newcode613
Documentation/usage/lilypond-book.itely:613: If a @code{tagline} is
required, either default or custom, then the
The tagline thing has nothing to do with the papersize; please place it
in a more appropriate location in the docs.
http://codereview.appspot.com/4289057/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes accidental suggestions in the beam collision engraver (issue4271054)
On Sun, Mar 20, 2011 at 8:41 AM, mts...@gmail.com wrote:
Reviewers: ,
Message:
Hey all,
A bug just hit the French list. It seems like a critical regression.
Hi,
There is not much else we can do: the suggestion accidental uses the
stem extent to determine Y positions, but that requires formatting the
beam, which looks at the Y position of the accidental again.
The intention of the fix is incorrect, but can you make the logic
explicit? That is, add an interface symbol for normal accidentals
(normal-accidental-interface, inline-accidental-interface, ... ?) and
acknowledge that explicitly? If not, we will screw in the same way
for any other accidental-like grob, eg. TrillPitchAccidental).
Also, add this snippet to the regtest:
{
\set suggestAccidentals = ##t
a'8[ fis'16 g'16]
}
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes accidental suggestions in the beam collision engraver (issue4271054)
On 11-03-20 05:41 AM, mts...@gmail.com wrote:
Reviewers: ,
Message:
Hey all,
A bug just hit the French list. It seems like a critical regression.
\score { %avec surcharge des ligatures double croches
allongées
\new Staff {
\time 2/2
\set suggestAccidentals = ##t
g'4 fis'8 [ g'8 ] a'8 [ g'8 a'16 g'16 fis'!16 e'16 ] |
d'1
}
}
\score { %sans surcharge des ligatures : bon
\new Staff {
\time 2/2
\set suggestAccidentals = ##t
g'4 fis'8 g'8 a'8 g'8 a'16 g'16 fis'!16 e'16|
d'1
}
}
This patch proposes a fix.
Cheers,
Mike
Description:
Fixes accidental suggestions in the beam collision engraver
Please review this at http://codereview.appspot.com/4271054/
Affected files:
M lily/beam-collision-engraver.cc
Index: lily/beam-collision-engraver.cc
diff --git a/lily/beam-collision-engraver.cc
b/lily/beam-collision-engraver.cc
index
39e614c2a15dea10f3b72f88110959c35dc389a1..e0dade7b8ea3bc4d2f9eea3d4437b94102f85c80
100644
--- a/lily/beam-collision-engraver.cc
+++ b/lily/beam-collision-engraver.cc
@@ -160,7 +160,8 @@ Beam_collision_engraver::acknowledge_note_head
(Grob_info i)
void
Beam_collision_engraver::acknowledge_accidental (Grob_info i)
{
- covered_grobs_.push_back (i.grob ());
+ if (!i.grob ()-internal_has_interface (ly_symbol2scm
(accidental-suggestion-interface)))
+covered_grobs_.push_back (i.grob ());
}
void
Added as issue 1570, Mike.
Colin Campbell
Bug Squad
--
The test of our progress is not whether we add more to the abundance
of those who have much, it is whether we provide enough for those who
have too little.
-Franklin D. Roosevelt, 32nd US President (1882-1945)
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes accidental suggestions in the beam collision engraver (issue4271054)
On Sun, Mar 20, 2011 at 10:59 PM, Han-Wen Nienhuys hanw...@gmail.com wrote: On Sun, Mar 20, 2011 at 8:41 AM, mts...@gmail.com wrote: Reviewers: , Message: Hey all, A bug just hit the French list. It seems like a critical regression. Hi, There is not much else we can do: the suggestion accidental uses the stem extent to determine Y positions, but that requires formatting the beam, which looks at the Y position of the accidental again. The intention of the fix is incorrect, but can you make the logic I mean: it's correct. (d'oh) -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
