to follow
David K's advice to use `hollow-duration-log-min' instead of
`hollow-duration-min'...
Okay, another reworked patch enclosed.
Lukas
From 830a24bb572c9a7226379f6a170a08565751a0d5 Mon Sep 17 00:00:00 2001
From: Lukas Pietsch
Date: Sun, 1 Mar 2015 20:00:45 +0100
Subject: [
Lukas Pietsch freenet.de> writes:
> Enclosing a reworked patch for review, with the property renamed and the
> new semantics as discussed.
Sorry, please ignore this one, there were still errors in it. Another
question: is there a handy type predicate to declare a grob property that
On 2015-02-28 21:38, Lukas Pietsch wrote:
Depends on what is affected. If you have properties only affecting
noteheads, the note-head-interface is the place for them.
Ah, okay. The one we were talking about would be needed both on notehead and
on stem grobs, and there may be another one with
David Kastrup gnu.org> writes:
> > Sorry for repeating myself, but this part of my question may have gone
> > unnoticed in the thread above. Could I have some advice on this? Should I be
> > defining a new interface for specialized mensural-related grob properties?
>
> Depends on what is affecte
Lukas Pietsch freenet.de> writes:
> Another technical question: I found that apparently if I'm going to declare
> these new grob properties in scm/define-grob-properties.scm, I'll also have
> to declare them as part of some interface somewhere else, otherwise I get
> &
Werner LEMBERG gnu.org> writes:
> >> "hollow=1" would then be the default for modern notation.
> >
> > minHollowDurationLog would be more descriptive.
>
> What an ugly name, but I agree that it is more descriptive than
> `hollow' and thus probably better.
Shouldn't grob properties be spelled w
Werner LEMBERG gnu.org> writes:
>
>
> >> Well, accepting a bool is not a bad idea. For example,
> >>
> >> \override NoteHead.hollow = ##f
> >>
> >> could undo
> >>
> >> \override NoteHead.hollow = #2
> >
> > #f is accepted for all properties anyway. #t isn't by default, however.
>
> Ah,
Benkő Pál gmail.com> writes:
>
> as far as I know when flagged notes with hollow heads are used, they are
> used exclusively, i.e. there are no black notes at all (more precisely, all
> black notes count as notae coloratae, which is a separate notehead style
> anyway, and from duration point of
everything else should be doable in Scheme.
Regards,
Lukas
From fca098701f938fa1ea608db91340dd290fb06a97 Mon Sep 17 00:00:00 2001
From: Lukas Pietsch
Date: Thu, 26 Feb 2015 19:11:27 +0100
Subject: [PATCH 3/3] Support for flagged semiminims in mensural notation.
New grob property "mensural-bl
> On 24/02/15 07:38, Werner LEMBERG wrote:
> >>> To simplify the process, I suggest that you get write access to the
> >>> lilypond git repository so that you can add such incremental
> >>> patches to one or more separate branches (I like this method
> >>> bettern than the `modern' way of forking l
Joram Berger gmx.de> writes:
> once again, I am no expert on ancient notation. So I don't know whether the
> length of the stems in your renaissance style are required to be exactly
as long
> as they are now. They roughly end in the middle of a staff space for notes on
> this position and on a st
Werner LEMBERG gnu.org> writes:
> No. Not a patch, but a series of patches, adding the stuff in small,
> incremental steps that are easy to review. I'm willing to proof-read
> all changes to the Metafont sources.
>
> To simplify the process, I suggest that you get write access to the
> lilyp
David Kastrup gnu.org> writes:
> You state "The notation samples, which include numerous highly uncommon
> and idiosyncratic forms, will be encoded in the corpus in an XML-based
> format". If the forms are highly uncommon and idiosyncratic, can they
> be described by an XML-based expressions tha
On Fri, 2011-01-07 at 17:50 +, Neil Puttock wrote:
> On 7 January 2011 02:50, Andrew Hawryluk wrote:
> > I tried running it on a current development snapshot this week, but it
> > didn't have enough memory to run nicely and bogged down my computer
> > with swap traffic (I've got 2 MB here). I
On Fri, 2011-01-07 at 07:10 -0700, Carl Sorensen wrote:
> >
> > Thanks a lot! As for the warnings, I too was getting the "cannot align
> > on self: empty element" ones, and found no way of getting rid of them.
> > Maybe it's something to do with Lilypond not liking the way I removed
> > the standa
On Fri, 2011-01-07 at 13:08 +, James Lowe wrote:
>
> I ran this with 2.13.45 and it compiles with some warnings (see
> attached zip of log file).
>
> However, this is wonderful stuff!
>
> Also your PDF is very informative and it would be nice to incorporate
> this into our own Notation R
On Thu, 2011-01-06 at 10:49 +0100, Benkő Pál wrote:
> > According to Apel (1962: 99), the general rule would seem to be that the dot
> > should be on the right if it applies to the final note of the whole
> > ligature, but on top if it is anywhere else (flexa or no flexa). He has one
> > example o
On Thu, 2011-01-06 at 08:44 +, benko@gmail.com wrote:
> One thing I forgot to mention: I've also rewritten dot handling within
> ligatures. The old code
> - didn't avoid staff lines
> - didn't conform actual usage: dotting notes above is not a practice,
> only if they are first within a f
On Tue, 2011-01-04 at 11:49 +0100, Werner LEMBERG wrote:
> Very impressive! Could you try to make it work with the current
> development version? The next steps could then be adding the missing
> glyph shapes to the lilypond fonts, followed by either writing a new
> engraver or modifying/fixing/
Karl Hammar aspodata.se> writes:
> On line 22 in the ly-file:
>
> %% Accidentals are valid only once (same as
>
> Shouldn't the accidental be valid for the next note and any same
> repeted note, this has bothered me with the current white mesural
> support. E.g. if you say "bes bes bes",
Hi, I'm quite new to Lilypond programming, but I thought I'd jump in at what
seemed to me to be pretty much the deep end, and try if I could get black
mensural notation implemented. Here's what I've come up with so far:
http://lukas-pietsch.de/Music/blackmensural.ly (source file)
http://lukas-piet
21 matches
Mail list logo
