> [...] This is what I've drawn out: When notating a chant, anyone who
> places full-height single or double lines anywhere but the end of a
> phrase is a sheep, a klutz, and an ignoramus.
:-)
> My main doubt is whether this restriction is limited to church
> music. I hope to understand whethe
Everything I know about 16th-Century Italian I learned from 20th-Century
Spanish. I hope that someone here is able and willing to check my guesses
about this.
The following text seems to follow an introduction to mensural rests, and it
surrounds a figure of a single bar line and a double bar l
PATCH 5/5] Support for flagged semiminims in mensural notation.
New grob property "hollow-duration-min" to set the cutoff level between
hollow and black notes, and corresponding behavior of flags/beams.
---
input/regression/flagged-seminimim.ly | 42 +++
li
Werner LEMBERG writes:
>> If it's too much trouble, I guess it might be preferable to drop the
>> idea with the boolean values again, as it isn't really that crucial
>> for the intended functionality anyway.
>
> This is OK with me. I only wonder whether it's better to follow
> David K's advice t
Lukas Pietsch writes:
> 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
> If it's too much trouble, I guess it might be preferable to drop the
> idea with the boolean values again, as it isn't really that crucial
> for the intended functionality anyway.
This is OK with me. I only wonder whether it's better to follow
David K's advice to use `hollow-duration-log-min'
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
can take eit
+0100
Subject: [PATCH 5/5] Support for flagged semiminims in mensural notation.
New grob property "hollow-duration-min" to set the cutoff level between
hollow and black notes, and corresponding behavior of flags/beams.
---
input/regression/flagged-seminimim.ly | 42 +++
On Feb 28, 2015, at 11:34 , David Nalesnik wrote:
> "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.
>>
>> Should
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 writes:
> 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
>
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
> "cannot find interface for pr
On Sat, Feb 28, 2015 at 10:14 AM, Lukas Pietsch
wrote:
> 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
> > `hol
Werner LEMBERG 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.
I'd put min last. Sorts better, sounds better.
ho
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
>> "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.
Werner
___
lilypond-devel mailing
On Feb 28, 2015, at 09:55 , Lukas Pietsch wrote:
> I'm still not quite sure what you would expect the semantics to be. If we
> keep it as a numeric property, but call it "hollow" rather than something
> involving "black", we'll first of all have to redefine it: not "duration
> beyond which notes
>> Ah, ok. On the other hand, having the possibility to say
>>
>> \override NoteHead.hollow = ##t
>>
>> to always enforce hollow noteheads makes probably sense, too.
>
> I'm still not quite sure what you would expect the semantics to be.
I'm poking with a stick in the dark :-) In this very cas
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,
>> 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 view they behave just as their
>> 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, ok. On the other hand, having the possibility to say
\ov
Werner LEMBERG writes:
>>> I'm not happy about the parameter name `mensural-blacklevel'. What
>>> about simply `hollow'?
>>
>> No problem about renaming it, as far as I'm concerned, but wouldn't "hollow"
>> imply a simple boolean switch, rather than a numeric scale?
>
> Well, accepting a bool i
>> I'm not happy about the parameter name `mensural-blacklevel'. What
>> about simply `hollow'?
>
> No problem about renaming it, as far as I'm concerned, but wouldn't "hollow"
> imply a simple boolean switch, rather than a numeric scale?
Well, accepting a bool is not a bad idea. For example,
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
hello Lukas,
> here's my next portion of patches for the extended mensural notation support
> I mentioned the other day. This bit is to get full support for the various
> options relating to black and hollow (unflagged and flagged) small note
> values (crotchets and below)
Lukas Pietsch writes:
> Werner LEMBERG gnu.org> writes:
>
>>
>> I'm not happy about the parameter name `mensural-blacklevel'. What
>> about simply `hollow'?
>
> No problem about renaming it, as far as I'm concerned, but wouldn't "hollow"
> imply a simple boolean switch, rather than a numeric s
> here's my next portion of patches for the extended mensural notation
> support I mentioned the other day.
I'm not happy about the parameter name `mensural-blacklevel'. What
about simply `hollow'?
Werner
___
l
Hello list,
here's my next portion of patches for the extended mensural notation
support I mentioned the other day. This bit is to get full support for
the various options relating to black and hollow (unflagged and flagged)
small note values (crotchets and below), as discussed in sectio
Lukas
On 25/02/15 17:11, Lukas Pietsch wrote:
> David Kastrup gnu.org> writes:
>>
>> Developing the first patches does not require write access: the
>> development process in Git is primarily a local one. If there is
>> consent that Rietveld is not useful for looking at incremental patches
>> (I
Lukas Pietsch writes:
>> 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
> 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
- Original Message -
From: "Joram Berger"
To:
Sent: Tuesday, February 24, 2015 12:24 AM
Subject: Re: Draft: Extended mensural notation support
- How easy would is it to reuse the musical content of an ancient staff in
a
modern staff to show a modern equivalent?
This
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
Lukas,
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 lil
>> 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 lilypond at github, then
>> followed by push requests) –
Hi Lukas,
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 staff line for notes on a staf
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
just enhance
> the coverage of standard features of mensural notation: an improved
> glyph set for mainstream white notation, support for mainstream black
> notation, a consistent and user-friendly set of commands for such
> things as perfect/imperfect meters, rests, coloration and so on
7;s a matter of how best to make the basic Lilypond
system most efficiently extendable. I'd like to think of what I'm proposing
as a thing with two layers.
There is a set of core functional extensions that will just enhance the
coverage of standard features of mensural notation: an improved glyph
>>I have a working draft of the Lilypond coding, which involves quite
>>a bit of Scheme code, a patched Lilypond font with a section of new
>>proposed glyphs, and a few minor patches to Lilypond's C++ codebase.
>>Unfortunately, owing to the latter, the whole system currently works
>>only with a pa
do so.
Wow -- this seems like a tremendous amount of work! I'm basically
ignorant of mensural notation, but this seems like a great advance.
I think it should be implemented in LilyPond. And I think that the things
you have found in LilyPond that are inconsistent with best practices (e
s going to
present a new draft of it to the community some time during the next months.
Michael, if you want to see the current state of it, please feel free to
contact me privately.
Lukas
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/Black-mensural-notation-in-curren
- Original Message -
From: "MIchael McClimon"
To:
Sent: Friday, February 28, 2014 3:08 PM
Subject: Black mensural notation in current Lilypond
(First of all, I'm not subscribed to this list, so I'd appreciate it if
you
copied me at mich...@mcclimon.org on re
(First of all, I'm not subscribed to this list, so I'd appreciate it if you
copied me at mich...@mcclimon.org on replies to this.)
In the past, I've used Lukas Pietsch's Black Mensural plugin
(http://www.lukas-pietsch.de/Music/blackmensural.ly) to set black mensural
notation.
Hello,
2011/3/10 Carl Sorensen
>
> If you could get a closer shot of the desired clefs, I'd be happy to have a
> discussion with you about how much you're willing to pay for the clefs.
>
>
Here it is:
http://gregoriana.sk/gg/wp-content/uploads/c-clef1.png
http://gregoriana.sk/gg/wp-content/uploa
>>> Could I ask you for other improvement? I need two new mensural clef glyphs,
>>> which you can see in this picture:
>>> http://gregoriana.sk/gg/wp-content/uploads/p1020924.png
>>> The G and C clefs are what I am interested in.
>>>
>>> If you could do it, I can offer you to pay for it. Would it b
On 3/10/11 10:39 AM, "Benkő Pál" wrote:
> Dear Mr Klein,
>
> forwarding your request to the development community.
>
>> Could I ask you for other improvement? I need two new mensural clef glyphs,
>> which you can see in this picture:
>> http://gregoriana.sk/gg/wp-content/uploads/p1020924.png
>
Dear Mr Klein,
forwarding your request to the development community.
> Could I ask you for other improvement? I need two new mensural clef glyphs,
> which you can see in this picture:
> http://gregoriana.sk/gg/wp-content/uploads/p1020924.png
> The G and C clefs are what I am interested in.
>
> If
On 1/24/11 3:31 PM, "Benkő Pál" wrote:
>>> please advise me about regression tests: can I modify ligatures within
>>> mensural-ligatures.ly? if not, can I add new ones to the same file?
>>
>> Ancient music has been abandoned by developers for a number of years.
>> IMO, you may do whatever you t
On 2011/01/24 21:27:35, benko.pal wrote:
new patchset up.
please advise me about regression tests: can I modify ligatures within
mensural-ligatures.ly? if not, can I add new ones to the same file?
Ancient music has been abandoned by developers for a number of years.
IMO, you may do whatever
>> please advise me about regression tests: can I modify ligatures within
>> mensural-ligatures.ly? if not, can I add new ones to the same file?
>
> Ancient music has been abandoned by developers for a number of years.
> IMO, you may do whatever you think makes the most sense as you try to
> bring
new patchset up.
please advise me about regression tests: can I modify ligatures within
mensural-ligatures.ly? if not, can I add new ones to the same file?
http://codereview.appspot.com/3797046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
now I see I forgot to answer a question:
> http://codereview.appspot.com/3797046/diff/1/lily/mensural-ligature-engraver.cc#newcode380
> lily/mensural-ligature-engraver.cc:380: {
> Why put the {} in this case?
because variables defined there should not be seen in the default case.
p
hi Carl, thanks for reviewing!
> Let me start by saying I know *nothing* about mensural notation.
>
> The code looks good to me.
>
> I found only one real issue:
>
> LilyPond coding standards for C++ say that if there is only one
> statement in an if clause, we omit {} aro
Let me start by saying I know *nothing* about mensural notation.
The code looks good to me.
I found only one real issue:
LilyPond coding standards for C++ say that if there is only one
statement in an if clause, we omit {} around that clause.
I also had a question (and it probably doesn&#
On 1/23/11 6:20 AM, "Boris Shingarov" wrote:
> This looks like Issue 1098. That one was closed due to lack of
> reproducible scenario: my scores, too, were crashing Lilypond after
> growing above a certain size, but just like in your case, I can not
> reproduce it with a simple \repeat.
Please
This looks like Issue 1098. That one was closed due to lack of
reproducible scenario: my scores, too, were crashing Lilypond after
growing above a certain size, but just like in your case, I can not
reproduce it with a simple \repeat.
On 11-01-16 12:57 PM, Benkő Pál wrote:
following up mysel
following up myself:
[ after complaining about my large scores ]
>> This seems to work (at least, the regtests are OK and it doesn't
>> appear to break the interaction between page-count and
>> systems-per-page):
> [...]
>> I don't know why, though. :)
>
> it works for me in the sense that there'
> "Karl" == Karl Hammar writes:
Karl> On line 22 in the ly-file:
Karl> %% Accidentals are valid only once (same as
Karl> Shouldn't the accidental be valid for the next note and any same
Karl> repeted note, this has bothered me with the current white mesural
Karl>
On 7 January 2011 14:00, Lukas Pietsch 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.
They're caused by the following lines:
\override Score.BarLine #'stencil = #empty-stencil
\override
> This seems to work (at least, the regtests are OK and it doesn't
> appear to break the interaction between page-count and
> systems-per-page):
[...]
> I don't know why, though. :)
it works for me in the sense that there's no memory problem,
but doesn't work in the sense that now I get an overflo
On 7 January 2011 20:33, Neil Puttock wrote:
> On 7 January 2011 20:27, Benkő Pál wrote:
>
>> it may be related to Joe's recent patch 777066 about page
>> breaking. I can't compile my larger scores, it stops at the
>> same message and memory usage goes to the skies. I wanted
>> to investigate it
On 7 January 2011 20:27, Benkő Pál wrote:
> it may be related to Joe's recent patch 777066 about page
> breaking. I can't compile my larger scores, it stops at the
> same message and memory usage goes to the skies. I wanted
> to investigate it a bit more, but if anybody beats me...
I'm looking
> Windows 2.13.44 also works fine here, though I can't say the same for 2.13.45:
>
> Preprocessing graphical objects...
> Finding the ideal number of pages...
> Fitting music on 1 or 2 pages...
> This application has requested the Runtime to terminate it in an unusual way.
> Please contact the appl
On 7 January 2011 18:40, James Lowe wrote:
> I ran it on Windows 2.13.44 (not 45 as I first said) and it took a few
> seconds to complile and roughly 150Mb.
Windows 2.13.44 also works fine here, though I can't say the same for 2.13.45:
Preprocessing graphical objects...
Finding the ideal numbe
: Re: Black mensural notation
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 co
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 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 gave up on it before it
> finished. Does it take long to compil
hapes, I have to look very thoroughly
through the existing gregorian support and your stuff.
What I like best are the Ars subtilior flags; however,
that is a part which confuses me quite a bit. In particular,
what I've added as coloratio / black mensural notation
support is really just the hea
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
James Lowe:
...
> Lukas (although for some reason I am getting bounces from your email address
> so I hope you are reading this on the lists)!
Lukas cannot do anything about this except changing mail provider.
The mailing list should be fine.
You can do something by making sure the sending mail
On 1/7/11 7:00 AM, "Lukas Pietsch" wrote:
> 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 woul
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
: Black mensural notation
Lukas (although for some reason I am getting bounces from your email address so
I hope you are reading this on the lists)!
---
Is anyone else getting
10.mx.freenet.de rejected your message to the following e-mail addresses:
Lukas Pietsch (lukas.piet...@freenet.de
Am 07.01.2011 10:17, schrieb Benkő Pál:
>> Sometimes I have been confused by a punctus divisionis placed in the
>> middle above a ligature, but of course that's something different.
>
> wow, I have never seen such a thing! could you give an example?
The only one I could find quickly is from Apel
again, Apel probably saw more sources than I ever will...
or me, too. and I learnt mensural notation solely from Apel.
> Sometimes I have been confused by a punctus divisionis placed in the
> middle above a ligature, but of course that's somethin
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 gave up on it before it
finished. Does it take long to compile the PDF on your system?
Andrew
On Tue, Jan 4, 2011 at
Am 06.01.2011 10:56, schrieb Lukas Pietsch:
> 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 el
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
> > 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 flexa, see examples in
> > http://anaigeon.free.fr/mes
Am 04.01.2011 11:22, schrieb Lukas Pietsch:
> 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 fa
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
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 flexa, see examples in
http://anaigeon.free.fr/mes_facs/fsbarb.jpg
http:/
he ones in codex Chigi, see scans
in attachment to
http://lists.gnu.org/archive/html/lilypond-devel/2010-12/msg00398.html
thanks,
p
Description:
mensural notation improvements
- support coloratio (even in ligatures)
- more flexible ligatura shapes
Please review this at http://codereview.appspot.c
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",
Am Dienstag, 4. Januar 2011, um 12:55:25 schrieb Benkő Pál:
> I'll read your docs carefully (my first impression is: it's
> absolutely stunning), but in the meantime I want to let you
> know that I'm working on white mensural notation, and I've implemented
> a preli
hi Lukas,
> 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/Mus
Lukas:
> 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/Mus
> 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/black
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 (sourc
>> Especially the `sM2semimensural' in `parmesan20' (which I'm
>> currently looking at after applying the patch locally) looks very
>> strange, and I've never seen a similar note shape before. But I
>> suspect this is my lack of knowledge.
>
> I'll try to compile a list of online facsimiles.
Ye
hi all,
> Regarding the quality of the patch: It's just fine. However, I can't
> say anything about the details since my knowledge of mensural notation
> is very limited. Especially the `sM2semimensural' in `parmesan20'
> (which I'm currently looking at afte
>> the attached patch adds noteheads needed for black mensural
>> notation (BMN) and coloratio in white mensural notation (WMN).
>>
>> note that it's just the noteheads: in both BMN and coloratio
>> sections in WMN a fourth note looks like a flagged half n
On Mon, Nov 8, 2010 at 10:06 PM, Benkő Pál wrote:
> hi list,
Greetings Pál,
[CCing Werner "the glyph guy" Lemberg]
> the attached patch adds noteheads needed for black mensural notation (BMN)
> and coloratio in white mensural notation (WMN).
>
> note that it's j
hi Valentin,
>> the attached patch adds noteheads needed for black mensural notation (BMN)
>> and coloratio in white mensural notation (WMN).
>>
>> note that it's just the noteheads: in both BMN and coloratio sections
>> in WMN a fourth note looks like a flagged
hi list,
the attached patch adds noteheads needed for black mensural notation (BMN)
and coloratio in white mensural notation (WMN).
note that it's just the noteheads: in both BMN and coloratio sections
in WMN a fourth note looks like a flagged half note.
I could reach this look by the foll
Applied (in CVS).
Greetings,
Juergen
On Mon, 9 May 2005, Pal Benko wrote:
What about the remaining durations (maxima, ...) for petrucci style?
I guess, they should be the same as for mensural style?
Yes. These as well are quite close but not identical to those found
in Petrucci prints; they will d
What about the remaining durations (maxima, ...) for petrucci style?
I guess, they should be the same as for mensural style?
Yes. These as well are quite close but not identical to those found
in Petrucci prints; they will do.
p
___
lilypond-devel mailin
Hi Jürgen,
What I do not understand, if you want neo-mensural noteheads, why not just
doing "\override Voice.NoteHead #'style = #'neomensural"?
As far as I can see, the main difference between neomensural and mensural
notehead are (besides the different parameters) that mensural noteheads have
diam
1 - 100 of 121 matches
Mail list logo
