[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Slurs Rests Params Tab Score Gimp Accidentals
David Raleigh Arnold
Re: Slurs Rests Params Tab Score Gimp Accidentals
Tue, 13 Mar 2001 14:46:27 -0500
Jan Nieuwenhuizen wrote:
> \property Voice.Slur \set #'attachment = #'(head . head)
Great. It will look better than having one slur on the beam when all the
rest aren't, believe me.
> We only support nesting 2 deep: one slur, one phrasing mark.
If anyone can figure out what nesting 3 deep might mean, he will ask for
it, I'm sure. Let's see. If I have this chord....;-). I'm very grateful
for it, honest.
> > Why can't I enter rc'4 to put r4 at c' on the staff?
> That syntax would be difficult, but you can do:
> \property Voice.Rest \set #'staff-position = #4
Noted for future reference. Thank you. Jeff Covey needs that, or needed
That's 1.3? No way or ok with 1.2? Back to the default how?
(I'm doing very simple stuff right now in one and two parts, and I like
a compile that takes less than a second, but I will need 3 parts on one
staff really badly soon, but I will upgrade before I tackle 3 parts on
There will never come a time when you can do 3 parts on one staff
without radical differences in the desirable vertical rest spacing
depending on which part a rest is in. With one staff in two parts, you
can always cross parts if you have to work tight vertically, so you
never really *need* it, although it looks better if persistent rests in
one part don't wander up and down so much. The syntax would be
difficult, but I know you can do it. :-)
A plotter draws lines. A copper plate can print lines. A printer only
prints dots. When you are going to make a pdf file out of it, or scan
it, or sacrifice resolution for smaller file size, it may make a
difference in how thin a line you can tolerate partly because it is
*gray* not black when it is printed.
> the default is 0.8 staff-line-thickness, which seems to work well on
> printers that print lines :-)
No, it doesn't work well at all. Of course engravers had different stem
and staffline thicknesses. They used different tools to draw them. It
means nothing. I think it *very* probable that the reason that the stems
were made noticeably thinner was because engravers were not *capable* of
making them exactly the same. They were allowing for human error, just
as they did with horizontal shift distances. If the stems were almost
the same as the lines, the reader would compare them to the lines, and
the stems would therefore not appear to be as uniform. I propounded a
theory to you: For maximum legibility, the stems and stafflines should
be of exactly the same thickness in all cases, because both contact
noteheads. You choose to ridicule it, but this theory can be proved or
disproved. Compare scores side by side at a distance, and/or with less
light. Which would you rather read for hours? I know the answer because
I made that test, and thanks to you I was able to make the change. The
test is worth making. I hope everyone reading this will make it. I don't
want your eyesight to suffer any longer. I don't want you to be blinded
by allowance for the human errors of dead people. :-)
> Specifying durations is lots simpler to implement, which just means
> that printing lyrics could be made available earlier.
Hooray! The answer I was looking for! And now you can do tab in a
similar way? :-)
I wish I could persuade you that tab is not an alternative to notation.
It is merely string and finger placement. It is only necessary to attach
to each note, similarly to lyrics, the difference being that if there is
not more than one voice in the notation staff you very probably have bad
notation rather than a good melody.
> Huh? No, if you want use any definitions in \score, you must define
> them first, ie, before you use them.
defs for all scores
defs for 1 only
defs for 2 (and 1 *if* fallen through)
defs for 3 (and 2 and 1 *if* fallen through)
If Lily can stop reading when it finds the first definition it is
seeking instead of the last, I would think it would be a hair more
efficient. If every voice has a unique name:
Code stuff read the most, read first
Just a thought. I was surprised the first time I looked at a .ly file
that the score block was at the end. Not as convenient for cat
notes.file r-arrow r-arrow foo.ly, etc. :-)
It finally penetrated my thick skull that it doesn't make a whole lot of
sense to dump into a vector drawing program if you have no vector fonts
yet. For now, PS is it, right? Why not dump into the gimp now, rather
than something else later? Almost all minor adjustments involve moving
something a little bit rather than drawing anyway, and of course one can
draw in the gimp if one wants to.
You asked if there should be changes in accidental defaults.
It is best if the persistence of accidentals applies to the voice, not
the staff. It is to be preferred IMHO especially for a conductor's piano
reduction, a piece that is a version of a score for multiple
voices/instruments, a piece in that style, a piece similar, actually
anything at all in tonal music! It helps the reader and the writer to
think in terms of voices. I don't think it helps to worry about what's
correct or incorrect here. What is least surprising has been debated to
death already, without useful result. It is not helpful to try to prove
that the second sharp is or is not correct or incorrect or is surprising
or not. I think therefore that it would be very good to have some kind
of setting for this, like voice-persist-accidentals or
staff-persist-accidentals, to firmly stake out neutral territory.
If this setting already exists, my apologies and thanks. And more
thanks. And more thanks to all, especially Mats. :-)