failed assertion in lilypond
[CVS 2004-09-15 7:35] lilypond stopped with lilypond: .../flower/include/array.hh:149: T ArrayT::elem_ref(int) const [with T = Slur_score]: Assertion `i =0isize_' failed. Aborted I've sent the input files to Han-Wen privately. Werner ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: Male/female/other
Engraving was a highly specialized skill, a craftsman had to complete around five years of training before she could be a master engraver. Engraving was a highly specialized skill; note change in punctuation craftsmen Had to complete about five years of training before they could become master engravers. If the musician looks away once or has a lapse in her concentration, she will have lost her place on the page. Musicians who look away one or have lapses in concentration will easily lose their place on the page. Carl Sorensen ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
[Fwd: Re: tweaking output in 2.3.16]
Could any of you main hackers on lilypond-devel answer this question, I have no idea. /Mats Original Message Subject: Re: tweaking output in 2.3.16 Date: Tue, 14 Sep 2004 13:58:01 -0400 From: J. Scott Amort [EMAIL PROTECTED] To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] On Sun, 2004-09-12 at 13:19 -0400, J. Scott Amort wrote: Hi, As a means of learning the 'inner' workings of lilypond, I've been trying to reproduce the exact layout of some complex scores. I've read through the manual and in consultation with the Program Reference area, I've been able to adjust the default layout quite well to suit my needs. However, there are two areas that I can't seem to find a solution - slurs and spanners (specifically, hairpins and trills). Regarding the manual positioning of slurs, I have found the height-limit property of the Slur object to be useful in extending the arc of the slur (to avoid collisions with some elements), but, I can't seem to find a way to adjust the positioning of the end points of the slur (i.e. closer to, or further away from the notehead). In the reference for 2.2.6, there is an attachment-offset property that seems to handle this sort of adjustment, but it does not appear in the 2.3.16 reference. Is there are way to do this in 2.3.x? Secondly, I would like to be able to tweak the length of spanner objects (specifically the Hairpin and TrillSpanner). I don't seem to see any reference to a property that allows for this - is it possible? Thanks for any help! Best Regards, Scott No suggestions? Is it at all possible to modify the location/shape of slurs and hairpins? Thanks again. Best, Scott ___ lilypond-user mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-user -- = Mats Bengtsson Signal Processing Signals, Sensors and Systems Royal Institute of Technology SE-100 44 STOCKHOLM Sweden Phone: (+46) 8 790 8463 Fax: (+46) 8 790 7260 Email: [EMAIL PROTECTED] WWW: http://www.s3.kth.se/~mabe = ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: solid background for text signs
---BeginMessage--- Thinking further more, any bar line should never cross a text sign (bar lines aren't so important anyway, because you have the measure timing given) by default. But note heads, stems etc. should stay as they are now and text solid background should be optional or even not needed in many cases (you can ident a sign a bit to avoid collision with a stem for example). In the previous example (Chopin's Etude), this could be seen where the bar line hides behind /molto legato/ sign, but a triplet number is in front of the sign, but it isn't annoying. So my suggestion is that bar line should always hide behind text signs and other elements are always in front of the sign (or optionally behind). - Matevz Matevz Jekovec wrote: I suggest the following new feature. As seen in many sources (currently looking at Henle urtext Chopin's Etudes), expression text signs (cresc., ritardando, sotto voce...) have solid white background, so the bar lines don't mix up with them. Usually, we can avoid hitting a slur, a stem or a dynamic marking, but hardly a bar line. IMO, this shouldn't be a default setting for all the text signs now (sometimes, a short pin of a note beam won't do any harm to a large /fortissimo/ sign), but should allow being optional. I attached a scanned part of the Chopin's Etude op.25 no.2. Notice the /molto legato/ sign. - Matevz ---End Message--- ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Percussion notation
First off, let me say thank you to the developers for LilyPond; it is a
wonderful piece of software. However, with that said, I would like to
make a request to the developers for improving some of the methods used
for percussion notation.
Most engravers overlook the notation quirks involved with writing for
percussion instruments, though LilyPond has done very well for the most
part. I've searched through the mailing list archives, and while some
of these issues have been brought up in the past, it seems nothing much
became of it.
The Percussive Art Society's International Drum Rudiments, found at
http://pas.org/Publications/rudiments.cfm, can be used as a reference
for the following items:
Rolls - Using tremolo repeats, one can get something close to what's
known in the percussion world as a double-stroke roll. The problem
with this, though, is that if using a tremolo repeat on a beamed note,
the tremolo is drawn horizontal instead on angled. This is too hard to
read, as the tremolo is aligned with the lines of the staff. Also, if
a tremolo repeat is drawn on, for example, a single eighth note, the
stem is lengthened too much, causing other issues, and makes it stick
out like a sore thumb, so to speak. Note also, the buzz, or multiple
bounce, roll which is drawn with the letter Z through the stem. I know
this can be achieved by other means, but making this part of the
standard syntax would be a big help.
Flams - It would be very handy if one could write something like \flam
sn16 or \flam bd4 instead of the current method of \acciaccatura sn8
sn16 and \acciaccatura bd8 bd4. Since flams are nearly always written
equivalent to \acciaccatura voice8 voice, this would be handy. If a
flam between different voices is desired, then the current method could
be used.
Drags/Ruffs - Similar to flams, the current method is something like
\acciaccatura { sn16[ sn] } sn4. Drags are nearly always written
equivalent to \acciaccatura { voice16[ voice] } voice, so something
like \drag (or \ruff) sn4 would be a real time-saver. The same as with
flams, if a drag between different voices is desired, then the current
method could be used.
Ghost notes - It is very common to have ghost notes, which are simply
notes in parentheses, in drum set notation. I've checked out
molecule-hacking.ly for doing this, but why can't this be part of the
standard syntax?
All of the aforementioned items are very commonly used standards in
percussion music. If these things were introduced/corrected in a
future version of LilyPond, it would be a huge boon for percussionists
looking to write music for their instrument.
I'm not much of a developer, although I do dabble in it occasionally.
I don't have much spare time to try to implement these things myself,
though I would be interested in learning and helping out as much as
possible if someone could point me in the right direction.
Thanks for listening, and thank you again to the developers for
creating an otherwise great tool for musicians.
--
Mike Irwin
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Does -f tex --tex influence char selection?
On Wed, 15 Sep 2004, Han-Wen Nienhuys wrote: [EMAIL PROTECTED] writes: Seems ok here, also with -f tex --tex. That is, the result looks for you pretty much like the attachment that I sent? That would be extremely strange, because in the manual on lilypond.org (as well as in my local repository here) it looks wrong; i.e. for both, you and me, running from command line seems to work while building the docu does not. I might be mistaken, but I see ligatures and an ancient clef at http://www.lilypond.org/doc/v2.3/Documentation/user/out-www/lilypond/White-mensural-ligatures.html#White-mensural-ligatures it could be that the previous update was before I cleaned the fonts, though. I do get a longa printed through the 2nd ligature. Is that what you mean? Exactly, that is what I am talking about. It should be a short note head (much like a brevis), without cauda, just like in the attachment that I sent. I get that longa from the command line as well, both with -f tex and with direct PS. Ah, ok, thanks, that is what I wanted to know (though this sounds now even more confusing to me). I guess I have to debug lily's TeX output to track down this bug. This may take a while... Thanks greetings, Jürgen ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
convert-ly on itely examples?
Is there an easy way to run convert-ly on the files in Documentation/user/ in order to update them? If there's just a few places, like the change between \stemBoth to \stemNeutral, I can fix them manually, but if there's an automatic way that'd be preferable. :) Cheers, - Graham ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
@internalsref{foo}
@internalsref{foo} creates see _foo_.
This results in Accidentals are
typeset for each voice, but they @emph{are} canceled across voices in
the same @internalsref{Staff}.
turning into
Accidentals are typeset for each voice, but they are canceled across
voices in the same see Staff .
Has @internalsref always created the extra see at the beginning, or
was this a recent change? If it was recent, then why? (I'll have to
reword a lot of places where it's used so that the sentence will make
sense)
Cheers,
- Graham
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
bug or bad wording in manual?
no-reset
This is the same as default but with accidentals lasting forever
and not only until the next measure
If I understand that sentence correctly, then in the below example
(taken from the manual, BTW), the second cis should have no accidental.
However, in 2.3.16 it does. Is this a bug, or have I misunderstood
the no-rest style?
\version 2.3.16
\bookpaper {raggedright = ##t }
{ \relative c' {
#(set-accidental-style 'no-reset)
c1 cis cis c
}}
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Does -f tex --tex influence char selection?
Hi! FYI: I guess I finally found the bug. There was a name clash between two font characters in the third argument of the fet_beginchar () macro due to a typo. It looks like this clash resulted in corrupted .pfa files, while other font-related files did not seem to be affected. Please note that the font has now changed again... There were also two other not directly related bugs, which I also corrected. Greetings, Jürgen ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
@internalsref{foo}
[EMAIL PROTECTED] writes:
@internalsref{foo} creates see _foo_.
This results in Accidentals are
typeset for each voice, but they @emph{are} canceled across voices in
the same @internalsref{Staff}.
turning into
Accidentals are typeset for each voice, but they are canceled across
voices in the same see Staff .
Has @internalsref always created the extra see at the beginning, or
was this a recent change? If it was recent, then why? (I'll have to
reword a lot of places where it's used so that the sentence will make
sense)
No, this is unintentional; @internalsref is a macro. We may have to
adjust the macro definition.
--
Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
bug or bad wording in manual?
bug. [EMAIL PROTECTED] writes: no-reset This is the same as default but with accidentals lasting forever and not only until the next measure If I understand that sentence correctly, then in the below example (taken from the manual, BTW), the second cis should have no accidental. However, in 2.3.16 it does. Is this a bug, or have I misunderstood the no-rest style? -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
convert-ly on itely examples?
[EMAIL PROTECTED] writes: Is there an easy way to run convert-ly on the files in Documentation/user/ in order to update them? If there's just a few places, like the change between \stemBoth to \stemNeutral, I can fix them manually, but if there's an automatic way that'd be preferable. :) I usually do convert-ly --from=... --to=... --no-version *.itely but you can also use the --filter option of lilypond-book. -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
