Re: \cresc applies to the next note!
On Sat, Feb 28, 2009 at 10:37 PM, Frédéric Bron wrote: > > Because \dim starts on the next note, you have to put it before \ff > which is the contrary of what happens really! If you put \dim after > \ff, the "dim" starts on the next note and it is possible that the > "ff" and the "dim" are not put on the same line. > This illustrates perfectly why I would like that \cresc and \dim start > on the next note. You mean that you would like \cresc and \dim to start on the previous note, right? I hope I am following correctly. For example: g4 \< g g g \! g4 \cresc g g g \endcresc These two examples should have the same behavior, IMO. That is, the commands apply to the *previous* note. I think we need to rework \cresc, \dim, etc. so that they use a modified version of make-span-event (the procedure \cr, \decr, etc. use). Right now, with these commands, a SequentialMusic expression is created, so the behavior will only apply to notes *following* the command. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \cresc applies to the next note!
> I wrote something like this for my opera, using the 'tweaks acons > method. I'll see if I can find it back. Well thank you. I have downloaded your score and found \ind and \nind but both start on the next note. However, I like the syntax \ind #"cresc poco a poco". It is a bit more painful than what I propose \<"cresc poco a poco" but it can be done today without changing the parser. I have also seen that you do quite often such thing: c\ff \dim c c c\! which is what you think (dim starts after \ff) but which does not what you really want: \dim c\ff c c c\! Because \dim starts on the next note, you have to put it before \ff which is the contrary of what happens really! If you put \dim after \ff, the "dim" starts on the next note and it is possible that the "ff" and the "dim" are not put on the same line. This illustrates perfectly why I would like that \cresc and \dim start on the next note. F. Bron ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Re: patch for bug 729
On Sun, Mar 01, 2009 at 12:13:52AM +0100, Valentin Villenave wrote: > how about considering an LSR upgrade now? I distinctly remember asking you to do this in January, > Like, before the whole 2.13 bloody mess starts... Too late for that. I suppose that we *could* backport everything to stable/2.12, but I can't see this being worth it. > - How involved would it be? > - Do we have to download the lsr archive, update the whole thing by > ourselves and send the new tarball to Seba? Dunno. Ask him? > - How do we update snippets that do not have a \version string? Do we > concatenate one automatically, and then remove it? Umm, convert-ly --from=2.10.12 ? Dunno if that adds one automatically, but it's easy enough to remove \version "2.12.2" from all files in a directory. > - Do you want me to give Seba a ping? That sounds like a good idea. Cheers, - Graham Note to self: I should really eat breakfast before pouncing on people ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \cresc applies to the next note!
2009/2/22 Graham Percival : >> Is there a possibility to make \cresc form start on the previous note >> and not on the next note? > > Based on my recollection of the previous two times this was > discussed on the list (see archives), no. I wrote something like this for my opera, using the 'tweaks acons method. I'll see if I can find it back. Regards, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Named book file suffixes -- regtest?
On 2/28/09 5:37 PM, "Marek Klein" wrote: > > My current solution is: > (set! counter-alist (assoc-set! counter-alist output-suffix (1+ > output-count))) > > Reinhold said, it would be better to use ly:parser-define! instead of set! > But I don't understand how... NR says: > Function: ly:parser-define! parser-smob symbol val > > Bind symbol to val in parser-smob¹s module. > It's not clear enough for me... if I try for example: > (ly:parser-define! parser counter-alist (assoc-set! counter-alist > output-suffix (1+ output-count))) > I get following error: > > Parsing.../home/marek/lilypond/usr/share/lilypond/current/scm/lily-library.scm > :152:5: In procedure ly:parser-define! in expression (ly:parser-define! parser > counter-alist ...): > /home/marek/lilypond/usr/share/lilypond/current/scm/lily-library.scm:152:5: > Wrong type argument in position 2 (expecting symbol): () I think this error message says that it's expecting a symbol, and instead it gets an empty list, which is the value of counter-alist right now. So I think you should try (ly:parser-define! parser 'counter-alist (assoc-set! counter-alist output-suffix (1+ output-count))) This puts the symbol as the argument, rather than the value of the symbol, I think. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Re: patch for bug 729
On 2/28/09 3:43 PM, "John Mandereau" wrote: > Hi Carl, > Carl D. Sorensen a écrit : >> So, just for the record, I guess that the appropriate way to handle this >> would be to: >> >> 1. Search through input/lsr for relevant files. >> 2. Fix the snippet to make sure it compiles properly. >> 3. Copy the snippet to input/new >> 4. Delete the snippet from input/lsr >> >> Is that right? >> > Yes, except you shouldn't do 4, and don't forget some snippets > eventually come from LSR, not from input/new. We can't do anything about the snippets that come from LSR, can we? They're for the old release, so they can't be updated, IIUC. I thought that was why we had input/new, to handle snippets that had changed syntax from the currently-running LSR. > >> Plus, I guess that something like these needs to go into the CG, so that we >> never have to have this conversation on -devel again. And the frogs don't >> have to search the frogs archive either. >> > I added the fixing procedure you mentioned above, plus other LSR-related > stuff in the CG. Thanks, John! Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Named book file suffixes -- regtest?
2009/2/28 Carl D. Sorensen > > On 2/27/09 11:53 AM, "Reinhold Kainhofer" wrote: > > > > >>> What about set! versus ly:parser-define! ? > > > > I would rather use ly:parser-define!, if we can find out why it doesn't > work. > > It's simply cleaner than using a global variable... > > > > > > Marek, > > Can you try again with ly:parser-define!, and try to get some help from > lilypond-devel by describing in more detail how it doesn't work, i.e. what > the errors/error messages are? > > Thanks, > > Carl > > My current solution is: (set! counter-alist (assoc-set! counter-alist output-suffix (1+ output-count))) Reinhold said, it would be better to use ly:parser-define! instead of set! But I don't understand how... NR says: *Function:* *ly:parser-define!** parser-smob symbol val* Bind symbol to val in parser-smob’s module. It's not clear enough for me... if I try for example: (ly:parser-define! parser counter-alist (assoc-set! counter-alist output-suffix (1+ output-count))) I get following error: Parsing.../home/marek/lilypond/usr/share/lilypond/current/scm/lily-library.scm:152:5: In procedure ly:parser-define! in expression (ly:parser-define! parser counter-alist ...): /home/marek/lilypond/usr/share/lilypond/current/scm/lily-library.scm:152:5: Wrong type argument in position 2 (expecting symbol): () -- Marek Klein http://gregoriana.sk ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Re: patch for bug 729
2009/2/28 Carl D. Sorensen : > I've applied the patch, but it did not include modifications to > input/lsr/demo-midiinstruments.ly. > > We can do that once we get the answer about how to properly handle it. I've just done an LSR update, so it's been amended automatically with Andrew's new convert rule. I have a belated suggestion for the convert rule: the hash should be removed, otherwise it only picks up strings which follow the documentation guidelines. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Re: patch for bug 729
Neil, John, Graham, how about considering an LSR upgrade now? Like, before the whole 2.13 bloody mess starts... - How involved would it be? - Do we have to download the lsr archive, update the whole thing by ourselves and send the new tarball to Seba? - How do we update snippets that do not have a \version string? Do we concatenate one automatically, and then remove it? - Do you want me to give Seba a ping? Regards, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Re: patch for bug 729
2009/2/28 John Mandereau : > Hi Carl, > Carl D. Sorensen a écrit : >> >> So, just for the record, I guess that the appropriate way to handle this >> would be to: >> >> 1. Search through input/lsr for relevant files. >> 2. Fix the snippet to make sure it compiles properly. >> 3. Copy the snippet to input/new >> 4. Delete the snippet from input/lsr >> >> Is that right? >> > > Yes, except you shouldn't do 4, and don't forget some snippets eventually > come from LSR, not from input/new. I agree, though in the case of demo-midiinstruments.ly, there's no need for a copy in input/new, since the LSR version's automatically converted when makelsr.py is run. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Re: patch for bug 729
Hi Carl, Carl D. Sorensen a écrit : So, just for the record, I guess that the appropriate way to handle this would be to: 1. Search through input/lsr for relevant files. 2. Fix the snippet to make sure it compiles properly. 3. Copy the snippet to input/new 4. Delete the snippet from input/lsr Is that right? Yes, except you shouldn't do 4, and don't forget some snippets eventually come from LSR, not from input/new. Plus, I guess that something like these needs to go into the CG, so that we never have to have this conversation on -devel again. And the frogs don't have to search the frogs archive either. I added the fixing procedure you mentioned above, plus other LSR-related stuff in the CG. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Updates to the LM
Graham Percival a écrit : On Wed, Feb 25, 2009 at 11:18:32AM -, Trevor Daniels wrote: I think I've muddled through this and updated input/lsr with my new snippet. As this was the first time I've used makelsr.py there were lots of mysterious warnings, but it seems to have converted and copied the one file I needed successfully, so I selected this one file and placed it in input/lsr. As a general note, I would encourage people NOT to use makelsr.py unless they are very familiar with it. All it takes is one inexperienced (in this area) developer trying to fix a "simple" bug at the wrong time, and could result in many of us losing our entire personal data due to a rm -rf ~ system call within a snippet. This potential issue is important, but from now you can just say "Wanna know how to run makelsr.py? Please carefully read the fine CG!" ;-) Yeah, of course we all use an encrypted incremental backup system like tarsnap.com, and we all have separate user accounts for lilypond development so that any malicious snippet can't touch our personal files... Yes, we should; I almost do, except that I use two USB sticks and an USB disk for backup, and incremental often means using Git for me, even if it's not identical. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: an LM update
James
We discussed this last October, and I agreed to make the change in
2.13, but then the suggestion was made (by Mats):
Better yet, why can't the shorthand automatically "do the right
thing"? i.e.,
<< {} \\ {} >>
should be translated automagically into
<< {} \new Voice {} >>
I'd rather not waste time changing the documentation now if this
code change is likely to be implemented. So, what's the chance this
change will be made? I've no idea whether it is easy or difficult.
Trevor
- Original Message -
From: "James E. Bailey"
To: "lilypond-user Mailinglist" ;
"lilypond-devel"
Sent: Friday, February 27, 2009 9:54 PM
Subject: Fwd: an LM update
Since I haven't heard any feedback, I thought I would post to
the - devel list as well. Incidentally, I've answered questions
directly related to this twice in the last week or so.
Since the NR has the wonderful introduction to single-staff
polyphony, can this be simply inserted into the LM at the
appropriate point. I'm sure new users will have a much easier
time of engraving their music, and many problems can be avoided
later if this topic is presented in the LM the same way it's
presented in the NR. Unless, of course, there's a fundamental
reason not to. In which case, okay.
___
lilypond-user mailing list
lilypond-u...@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Completion_heads_engraver broken?
Joe Neeman wrote:
On Thu, 2009-02-26 at 13:24 +0100, Michael Käppler wrote:
Both fixed. Other comments?
Just one: can you set the environment variables GIT_AUTHOR_NAME and
GIT_AUTHOR_EMAIL so that an actual name and email show up in the patch?
Done.
>From fda64abf3730cbe811e292a17d58b23e4fd75f0c Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Michael=20K=C3=A4ppler?=
Date: Sat, 28 Feb 2009 10:20:38 +0100
Subject: [PATCH] This fixes an endless loop in duration.cc:67 when Duration::Duration(Rational r, bool scale) is called with
r.num() >= 2 * r.den(), f.e. the duration of a longa: r.num = 2, r.den = 1. If k < 0, the left-shifting-operator <<
returns an undefined value instead of right-shifting bits. The fix introduces a new function shift_left() in misc.hh,
which behaves different.
---
lily/duration.cc |6 +++---
lily/include/misc.hh |7 +++
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/lily/duration.cc b/lily/duration.cc
index af924bb..0b80b1c 100644
--- a/lily/duration.cc
+++ b/lily/duration.cc
@@ -53,16 +53,16 @@ Duration::Duration (Rational r, bool scale)
int p = r.num ();
int q = r.den ();
int k = intlog2 (q) - intlog2 (p);
- if ((p << k) < q)
+ if (shift_left(p, k) < q)
k++;
- assert ((p << k) >= q && (p << (k-1)) < q);
+ assert (shift_left(p, k) >= q && shift_left(p, (k-1)) < q);
/* If we were to write out log (p/q) in base 2, then the position of the
first non-zero bit (ie. k in our notation) would be the durlog
and the number of consecutive 1s after that bit would be the number of
dots */
- p = (p << k) - q;
+ p = shift_left(p, k) - q;
dots_ = 0;
while ((p *= 2) >= q)
{
diff --git a/lily/include/misc.hh b/lily/include/misc.hh
index e33d836..12392c0 100644
--- a/lily/include/misc.hh
+++ b/lily/include/misc.hh
@@ -28,6 +28,13 @@ sign (int i)
else return 0;
}
+inline int
+shift_left (int value, int shiftamount)
+{
+ if (shiftamount < 0) return (value >> -shiftamount);
+ else return (value << shiftamount);
+}
+
inline Real
linear_interpolate (Real x, Real x1, Real x2, Real y1, Real y2)
{
--
1.5.6
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
