Attached is a patch to fix the interpretation of dimensions for a
few output variables.
It's probably best if you sort the elements of the list
alphabetically.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
My special example is this where such a shorthand would be quite
convenient:
c4 c c \times 2/3 { r8 c16 } c8
This may have nothing to do with your proposal/question but as a
reader I would find your example much harder to read/sightread than
c4 c c \times 2/3 { r8[ c16] } c8
I don't think [] should even compile.
This is another possibility, yes. However, `c[]' is much easier to
type than `c\noBeam'. Additionally, it's not that an absurd notation
IMHO.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Werner LEMBERG wrote:
My special example is this where such a shorthand would be quite
convenient:
c4 c c \times 2/3 { r8 c16 } c8
This may have nothing to do with your proposal/question but as a
reader I would find your example much harder to read/sightread than
c4 c c
Yes. What I really would like to write is
c4 c c \times 2/3 { r8 c16[] } c8
and I just demonstrated a case where my proposed notation would be
helpful.
My point is that is it not helpful in this case because it produces
a notation which is IMO harder to read than the two
In the meantime, you can edit snippets and write them in both input/lsr
and input/new, so your work won't be overwritten next time someone runs
makelsr.py. We'll update snippets added input/new in LSR when it works
again.
If I understand you correctly, I shall
. edit nesting-staves.ly in
2008/9/5 Werner LEMBERG [EMAIL PROTECTED]:
it seems that the LSR won't be available soon.
BTW, I spoke with Seba:
We have to wait for a couple of weeks at most. Sebastiano is away, and
he told me the people he's been relying on haven't been able to
address the issues properly; however he feels
On Sun, Sep 7, 2008 at 3:21 AM, Werner LEMBERG [EMAIL PROTECTED] wrote:
This may have nothing to do with your proposal/question but as a
reader I would find your example much harder to read/sightread than
c4 c c \times 2/3 { r8[ c16] } c8
or
c4 c c \times 2/3 { r8[ c16 } c8]
Yes.
Some random comments:
+ // these contexts have a many-to-one relationship to handles_[]
+ struct Part_combine_outlets
+ {
+Context *null;
+Context *apart1;
+Context *apart2;
+Context *solo1;
+Context *solo2;
+Context *chords;
+Context *rests;
+ } ctx_;
+
+ //
2008/9/7 Patrick McCarty [EMAIL PROTECTED]:
Hello,
Attached is a patch to fix the interpretation of dimensions for a few
output variables. Currently, no matter the unit specified, the
dimensions for the variables listed in the patch are converted to
millimeters, but are interpreted as
On Sun, Sep 07, 2008 at 04:20:41PM +0100, Neil Puttock wrote:
Can you amend the section on annotating spacing to reflect the
changes? As far as I can see, all the annotations are shown in
staff-spaces only.
Just to be sure, are you referring to NR 4.6? I will take a look.
Does the paper
0001-std-vector.hh-build-fix.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
2008/9/5 Trevor Daniels [EMAIL PROTECTED]:
The GUB release 2.11.57 for Windows seems to have a problem on Vista SP1.
Greetings Trevor,
Actually this is a known (however annoying) bug, see
http://code.google.com/p/lilypond/issues/detail?id=668
Cheers,
Valentin
Thanks for letting me know, Valentin. Unlike last time, at least this
problem with Vista is not my fault - quite a relief! :)
For now I've gone back to 2.11.56, as it was impossible trying to run
lilypond-book on the docs - windows flashing everywhere and quite an
increase in processing
On Sun, Sep 07, 2008 at 09:33:09AM -0700, Patrick McCarty wrote:
On Sun, Sep 07, 2008 at 04:20:41PM +0100, Neil Puttock wrote:
Can you amend the section on annotating spacing to reflect the
changes? As far as I can see, all the annotations are shown in
staff-spaces only.
Just to be
On Sun, Sep 7, 2008 at 5:30 AM, Werner LEMBERG [EMAIL PROTECTED] wrote:
If I understand you correctly, I shall
. edit nesting-staves.ly in input/lsr
. duplicate the edited version in input/new
correct?
Yes, that's correct. Once the LSR is back online, we can move the
modified snippet
2008/9/7 Patrick McCarty [EMAIL PROTECTED]:
Okay, here is the updated patch. I updated the docs with the relevant
information (and did a general rewrite) and changed the regtest so
that it uses 3 pages again.
Cheers. It's applied.
Regards,
Neil
If we go through with this (which I doubt), the handles_ should be a
vector so we get bounds checking.
No argument there, but I don't understand what you mean by which I
doubt.
1. why is this a music property? Since it is all about contexts, I
think a context property would be better, at
On Sun, Sep 7, 2008 at 7:13 PM, Dan Eble [EMAIL PROTECTED] wrote:
If we go through with this (which I doubt), the handles_ should be a
vector so we get bounds checking.
No argument there, but I don't understand what you mean by which I doubt.
I doubt that we should have any sort of hard coded
I'm a little bit concerned that this might break on other platforms.
Is anyone familiar with the finesses of gcc's STL on various
platforms? Ideally, the
!HAVE_STL_DATA_METHOD
should probably die, but I don't know for which GCC versions we are
catering exactly.
--
Han-Wen Nienhuys -
20 matches
Mail list logo
