2013/1/30 :
> On 2013/01/29 17:25:19, Keith wrote:
>
>
> https://codereview.appspot.com/7220052/diff/4001/Documentation/learning/common-notation.itely#newcode506
>>
>> Documentation/learning/common-notation.itely:506: ratio of the number
>
> of notes
>>
>> to play in relation to the nominal
>> "..
intended change by
6f4893fa86378aa4a637eedbde5efc4680efa5bf
see
http://code.google.com/p/lilypond/issues/detail?id=2762
2013/4/5 Phil Holmes :
> Between 2.17.0 and 2.17.1 the behaviour of single staffline systems changed.
> The earlier behaviour had no barline; the latter has one. Images showing
> i've noticed something strange in mensural-ligatures.ly: in the last
> system, a flat symbol collides with the notes (attached). Should it
> look like this?
this is an impossible ligature, LilyPond should (but never did)
refuse it (with an explanation).
(note that accidentals are very rare in
hi David,
LilyPond barfs at
\book
{
\bookOutputName "foo"
{ a' }
}
git bisect gave me commit
24fdf0d37cec73564162324ab74ed5e3a6824e8c
to blame.
I don't know what to do, could you help me?
p
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Neil, David,
>>> I don't know what to do, could you help me?
>>
>> The attached patch works for me (haven't run make check on it though).
>
> I have taken the liberty of pushing it after looking it through
thanks to both of you: the patch works and I've learnt something
about LilyPond again.
p
> If I compile the following code (the start of Dufay's Ave Regina a3) with
> default settings, the stems follow modern style - some up, some down. For
> ancient music (I'm not sure when this ended, but it certainly applies around
> the period up to 1500) the stems were always up for normal notes;
> > music _prints_ do use downward stems, what's more, it's not at all
> > systematical, see e.g. the example in
> > http://code.google.com/p/lilypond/issues/detail?id=1839#c13
> > so we are left to apply manual \stemUp's and \stemDown's
> > (I use a global \stemUp and hack closing longae to \stemD
> I suggested it mainly b/c Ubuntu has very different UI in new
> releases, the Unity DE. For ubuntu 12.04 (next LTS release coming in
> spring) we may want to switch to xfce or switch to Debian completely.
> I can do whatever y'all want.
Lubuntu?
___
l
hi all,
I haven't got any reaction whatsoever since three weeks:
did I miss something?
http://codereview.appspot.com/5434061/
p
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
2011/12/15 Graham Percival :
> On Thu, Dec 15, 2011 at 09:47:28PM +0100, Benkő Pál wrote:
>> I haven't got any reaction whatsoever since three weeks:
>> did I miss something?
>> http://codereview.appspot.com/5434061/
>
> You've missed this:
> http://lilypond
hi Graham,
2011/12/20 Graham Percival :
> On Mon, Dec 19, 2011 at 08:41:36PM +, benko@gmail.com wrote:
>> patch rebased
>>
>> http://codereview.appspot.com/5434061/
>
> Unless you use the new git-cl to upload it, nobody will notice
> that you have updated your patch.
I used the new git-cl
patch rebased
http://codereview.appspot.com/5434061/
>>>
>>> Unless you use the new git-cl to upload it, nobody will notice
>>> that you have updated your patch.
>>> manually change it from Patch-needs_work to Patch-new.
> Added to the tracker as a committer.
thanks, Phil; label up
2011/12/23 Colin Campbell :
> For 22:00 MST Saturday The Night Before Christmas
>
> Enhancement:
> Issue 2109: do not tinker with the position of a pitched rest - R
> 5434061
could someone with push rights push this?
thanks,
p
___
lilypond-devel ma
> I'd like to see regtests in one of these commits that uses two or three
> simple functions in the form \foo c and <\foo c> that show this distinction.
>
> I thought that any music function could look through its argument, see if was
> an event chord or a note event, and act on it accordingly.
> Issue 2300: Patch: do not tinker with the position of a pitched rest - R
> 5434061
changed to need_work (didn't find a better way to express I'm working on it).
p
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailma
Colin Campbell írta (2012. április 2. 3:53):
> The items below are the result of a search on Rietveld for open items
> associated with the lilypond trunk. In some cases, the tracker item has
> been closed, so the Rietveld item should also be closed. In others, work
> continues but it would be go
hi Aleksandr,
2012/5/4 :
> For whatever reason, \alias Staff and \alias Voice do not bring in the
> performers. If I comment out the line \consists "Note_performer", I get
> no notes in the MIDI file, only the appropriate number of rests.
>
> I think this is also why Vaticana does not appear to w
dear team and Project Manager,
I'd like to get commit access.
sincerely,
Pál Benkő
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
hi Keith,
thanks for your review.
2012/5/23 :
> Looks good to me.
>
> The regtest changes look like improvements,
> although I wonder if the time-signature and repeat dots should simply
> center around the line closest to zero. If a user sets his
> line-positions entirely below zero, he might /
hi Marc,
>> http://codereview.appspot.com/6305115/diff/1/scm/bar-line.scm
>> File scm/bar-line.scm (right):
>>
>> http://codereview.appspot.com/6305115/diff/1/scm/bar-line.scm#newcode83
>> scm/bar-line.scm:83: (define (make-colon-bar-line grob)
>> I'm afraid this defun doesn't match the relevant p
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/Music/blackmensural.ly (source file)
> > 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
> if it helps to confirm that you are right, I might add my own experience
> with mensural sources. Composers/writers seem to literally avoid dotted
> notes in ligatures except (a) at the end of the ligature, or (b) on top
> of the first note of an obliqua, or (c) both. (a) and (b) are frequent,
>
hi all,
> As for how to proceed from here, I'm not quite sure, since "my" system
> now stands rather outside the normal architecture and its development
> process, and since consolidating it further would probably duplicate
> some of the work Pál has been doing on the white notation. Probably the
> 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
hi Joe,
>> > need to be careful about what happens when bar-size is set.
>> > Currently, your patch will break (for example) input/regression/drums.ly
>> > because it ignores bar-size.
>>
>> well, I think extent shouldn't be computed from size
>> as it loses information, but the other way round.
>
> 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
>> Good idea! I have to figure out the centering issues and how to convert
>> SCM to Interval, but this is a nice way.
>
> robust_scm2interval
thanks. I made the bare changes, it was quite straightforward after
all these exchanges; now comes convert-ly and the regtests.
I guess it will take much
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'
> thanks. I made the bare changes, it was quite straightforward after
> all these exchanges; now comes convert-ly and the regtests.
> I guess it will take much longer.
first patchset uploaded to
http://codereview.appspot.com/4025044/
p
___
lilypond-de
> Work on Critical issues has pretty much wound down. Carl asked
> about the status of 1474 recently; I'd like to take that a step
> further and ask for a dedicated volunteer to act as "shepherd" for
> each issue.
> - you *don't* need to program, or even understand programming
> (but that would b
>> I'll take care of 1472, but I need a copy of Valentin's opera.
>
> Valentin's opera is available as a git checkout:
> http://repo.or.cz/w/opera_libre.git
> but did you mean 1475 instead? Benk has claimed it.
>
>
> I tried briefly looking at the opera a few days ago, but it didn't
> compile in 2
2011/1/19 Graham Percival :
> On 1/19/11, Benkő Pál wrote:
>>> I tried briefly looking at the opera a few days ago, but it didn't
>>> compile in 2.12.3 or 2.13.46, so I gave up after a few minutes.
>>> Finding a minimal example that works in both 2.1
an example added.
http://code.google.com/p/lilypond/issues/detail?id=1475
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
> I am wondering if there is a way to hack the source to change the midi
> pitch values which are output when it renders. I want to do this so
> that I can remap those values to arbitrary frequencies for microtonal
> playback in a retunable software synth like puredata.
I hope the attachment can
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 {} around that clause.
that's
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
>> 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
> Your example of comma tuning was indeed the ticket I needed!!
great to hear!
> I've adapted your file to 31 equal temperament. (The files are
> attached for anyone who is interested.)
I don't know whether it's common knowledge, but I notate the
31-step octave with conventional accidentals:
c d
> Why is the french version of the chords.itely in this patch and none of
> the other languanges?
I grepped for bar-size, was surprised too, but didn't investigate further.
I'll do it again before sending the patches (and if I find anything new,
I'll upload it to Rietveld).
p
___
> I am aware that the mensural notation patch does not contain a
> regtest. I am arbitrarily and unilaterally deciding that this doesn't
> matter in this specific case. We pretty much abandoned ancient music
> a few years ago; Benko is a very good contributor; he can make (or
> modify) a regtest
> LGTM; please send me a git-format origin patch and I'll push it.
thanks!
p
0001-regtest-and-changes-for-mensural-ligature-improvemen.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman
hi all,
documentation of new features is at
http://codereview.appspot.com/3989049/
p
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
(I don't know what happened to my reply, trying again.)
2011/1/31 :
> Just some minor syntax changes to make it read better. I hope no one is
> offended.
on the contrary!
> http://codereview.appspot.com/3989049/diff/3002/Documentation/notation/ancient.itely
> File Documentation/notation/ancient
>> > http://codereview.appspot.com/3989049/diff/3002/Documentation/notation/ancient.itely#newcode966
>> > Documentation/notation/ancient.itely:966: \[ d\longa
>> > Can we put note durations for the first note of every new line (again as
>> > per the CG)?
>>
>> I'm afraid I don't get this. all firs
hi James,
> The CG asks that for every new line of music you put the note length
> of the first note of every measure that starts a new line,
> even though it is not technically needed.
>
> That's all.
>
> So for example
>
> \override NoteHead #'style = #'blackpetrucci
> a'8*4/3 a'
> \override N
> Pal, could you do that git pull, then send me git format-patch
> origin ? Now that we have James' approval, let's push your latest
> patch.
attached; thanks!
p
0001-document-new-mensural-ligature-features.patch
Description: Binary data
___
lilypond-
>> IIRC, "diatonic" can refer to any church mode.
>>
>> Let me rephrase / alter my initial suggestion: might it be worth
>> having some predefined scales for actually well-defined scales?
>> Like \major or \locrian or the like? They could go in a new
>> ly/*-init.ly file, or maybe something in scm
>> I think for these purposes all church modes are equivalent.
>> the different minor scales are truly different.
>
> Don't some church modes have an optional flat?
that's the concern of musica ficta, no need to handle it here.
>>> For pentatonic scales there are even more in common use,
>>> I be
> Thanks. This is good feedback. I agree that an extra argument could
> be useful. I think of this operation as transposition followed by
> inversion, so Pal's example could be implemented this way:
>
> %%
> modalTransposedInversion =
> #(define-m
>>> Has anyone checked them?
>>
>> custos.ly - the lines at the end of the mensural notation are much longer
>> in
>> .47 - see attached image - the red is the new, longer line. I don't
>> understand this and would need to raise it as a regression unless someone
>> can tell me it's deliberate and
> Pál changed 'mensural-ligatures.ly' and perhaps can comment on whether the new
> output is what he intended.
changes in dot placement is intended, see the thread starting at
http://lists.gnu.org/archive/html/lilypond-devel/2011-01/msg00168.html
spacing is different at least because there are mo
> Add Modal transformations
> http://codereview.appspot.com/4126042/
I think
http://codereview.appspot.com/4079064/
is newer.
p
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
> I've just uploaded the latest changes from Mike. These extend
> modalInversion to permit inversions around a pivot between two notes in
> the scale.
>
> There are also some minor changes suggested by Graham.
>
> Please review.
LGTM
> http://codereview.appspot.com/4079064/
> There's a long standing problem with unequally tempered key
> signatures. If the accidentals aren't halves, the MIDI production
> fails.
Please explain in more detail, I never had such problems with MIDI.
(other problems I did havelike nasty graphical output, or wrong
chords when I didn't move
> The patch works fine, but the documentation could be improved.
agreed.
> Expanding the example in a different section to show \inversion is not
> optimal.
sorry, I don't get that.
> We need an @lilypond{} immediately after the @example showing
> the syntax in the Inversion section.
>
> Also,
> A year ago, I added a section to the CG about having mentors for contributors:
> http://lilypond.org/doc/v2.13/Documentation/contributor/mentors
>
> Sadly, it didn't take off -- I took on two doc contributors (just like
> the Grand Documentation Project, albeit on a small scale), but there
> wer
>> as a start I'd take Graham Breed's microtonal thingy:
>> http://lists.gnu.org/archive/html/lilypond-devel/2011-02/msg00567.html
>
> I don't recommend that; Felipe has been working on microtonal
> notation support. See:
> http://code.google.com/p/lilypond/issues/detail?id=1278
> and the discussi
>> should I move retrograde into its own section now or is there a
>> volunteer who can improve the documentation on transpose and
>> inversion as well after pushing as is?
>
> I'm happy to fix up the documentation, so I will
> apply this as-is if I hear nothing contrary in the
> near future.
than
> as a start I'd take Graham Breed's microtonal thingy:
> http://lists.gnu.org/archive/html/lilypond-devel/2011-02/msg00567.html
I don't recommend that; Felipe has been working on microtonal
notation support. See:
http://code.google.com/p/lilypond/issues/detail?id=1278
> Pushed to git/origin/master 22 Feb 11
> d245674e0266cde01a425317fa28aeb792ce589d
> 7230509dd005d9bbc7b2a7f0a064abc2de3b0ce6
>
> plus doc changes
> 28c797d550d5557e75842c59a459aa48349e7ad5
> 94cce45d444cd6700d3f4df84cda68fb7de96cd7
thanks again!
p
___
Felipe,
I'm still far from digesting the whole, but this is really great work!
> 2. int vs Rational
>
>> Why not use a sequence of Rationals (rather than ints) to represent
>> the alteration?
>
>> If we use rational numbers, we can maintain backward compatibility.
>
>> The re-scaling of the alter
> The following (derived from an example in the manual) crashes:
>
> \include "makam.ly"
> mode = #`((6 . ,(- KOMA)) (3 . ,BAKIYE))
> \score {
> \relative c' {
> \set Staff.keyAlterationOrder = #mode
> \key c \mode
> c4 cc db fk
> gbm4 gfc gfb efk
> fk4 db cc c
> }
> \layout{}
>
>> huh, I understand less and less. I'll try this example;
>> my meantone tests are not crashing, they produce
>> correct MIDI (at least it sounds correct - I didn't think
>> MIDI has a concept of key signature); the signature
>> is missing from the score, though.
>
> If the key signature is missi
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
>>> 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
2011/5/9 :
> http://codereview.appspot.com/4490045/diff/1/lily/completion-note-heads-engraver.cc
> File lily/completion-note-heads-engraver.cc (right):
>
> http://codereview.appspot.com/4490045/diff/1/lily/completion-note-heads-engraver.cc#newcode204
> lily/completion-note-heads-engraver.cc:204:
> By maxima, I mean the glyph "rests.M3".
> I chose to use maximas because they are easier to read than two longas
> with many space in between.
> In such cases, this is mandatory :
> { \compressFullBarRests \time 4/1 R\longa*10 }
>
> http://codereview.appspot.com/4536068/
>
ok, I fully agree. so
aargh, that's not too readable.
what I actually suggest is replacing lines 204-207 of
> http://codereview.appspot.com/4490045/diff/12001/lily/completion-note-heads-engraver.cc
> File lily/completion-note-heads-engraver.cc (right):
204 if ((left_to_do_ - note_dur.get_length ()) > Rational (0
2011/5/28 :
> On 2011/05/28 16:13:43, benko.pal wrote:
>>
>> aargh, that's not too readable.
>> what I actually suggest is replacing lines 204-207 of
>
>> >
>
> http://codereview.appspot.com/4490045/diff/12001/lily/completion-note-heads-engraver.cc
>>
>> > File lily/completion-note-heads-engraver.
> Summary: { \key c \minor \transpose gis as { es } } produces feses in
> output. I think it would be better if it outputted es.
> I have a piece written in es minor, which contains a lot of sharps and
> naturals (along with passages of flat notes). I'd like to "transpose it
> enharmonically" so t
> Maybe i'll write something myself next week, especially if the result
> would be included in Lily (i mean, not as a helper function in the
> docs, but built in Lily). If you could write a very small example of
> how to use key signature in scheme code it would help me much - i can
> handle the al
hi Janek,
> look at scm/modal-transforms.scm. there's a scale parameter to some
> functions; those are called from ly/music-functions-init.ly from functions
> (e.g. modalTranspose) that still take scale as parameter. there are
> examples in NR 1.1.2 Modal transformations. the scale is a set;
>
>> well, it was nastier than I thought because of the current pitch
>> representation,
>> so I haven't done it as a patch but a standalone hack; there's also a
>> non-standard (E31) example.
>>
>> [...]
>>
> 2011/6/21 Felipe Gonçalves Assis :
>> Enharmonicity is just an equivalence relation respec
> I want to test your code thoroughly, but many things keep me busy all
> the time... I hope to have more time in a few days.
I want to look at Felipe's code more thoroughly, I didn't succeed
this weekend, perhaps midweek. I certainly have some ideas;
I think I understood his code and suggestions
in C++ there's std::cout, std::cerr and std::clog,
and I use all three in my private projects.
p
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
> To be honest, I never understood well how this bitset operator works.
adds trailing zeros in binary.
> What I see is that "2 << -i" gives the same result than "2^(-i+1)".
> I should have write "2 << (-i + 1)" instead of "/2"...
the +1 multiplies by 2, not divides.
perhaps the best would be 1
hi Bertrand,
I started at the patch but it's quite difficult for now,
I hope I'll have enough time in the evening. till then
could you tell me whether usable-duration-logs is
ordered? is it a range or can it have holes?
thanks,
p
___
lilypond-devel m
generally signed-unsigned problems are better solved
by casting to size_t, not to unsigned - size_t works
equally well in 32 bit and 64 bit mode. (even better,
some variables can be size_t instead of int.)
p
___
lilypond-devel mailing list
lilypond-dev
> \relative x??? { x
> Namely start with the starting pitch.
my two cents: I always do that.
p
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
>>> \relative x??? { x
>>> Namely start with the starting pitch.
>>
>> my two cents: I always do that.
>
> Would you be tempted to use either
> a) \relative f { x???
> b) \relative f??? { x
> (and which one?) if you realized it worked just the same?
well, b) is nearer to my current idiom;
I can se
>>> \relative x??? { x
>>> Namely start with the starting pitch.
>>
>> my two cents: I always do that.
>
> And my two cents: I never do that.
> My rationale: in an (admittedly quite rare) case i want to paste the
> contents of one relative to another relative, having various starting
> pitches forc
> Seems like I am starting the wrong popular revolution. I ask "Isn't
> \relative f nice?" and people say "Sure, but let's call it \relative { }
> instead, never mind that the name is taken."
> You are the second in a row, and if I understand "Basso Profundo"
> correctly (he has not followed up y
hi Bertrand,
> I am a total ligature newbie. But I see some stemmed notes in
> input/regression/mensural-ligatures.ly .
initial and middle stems are drawn separately (see later if-blocks
of MLP_STEM and add-join), final ones are part of a longa notehead.
> Of course, I agree that there's a bug.
hi all,
the patch is ok from my point of view. a minor question: the only change
in mensural-ligatures.ly is the version bump - is that needed?
>> Do you know what neomensural and mensural styles are inspired of?
I believe it uses the shapes of noteheads found in manuscript,
but scales them to
2011/9/14 Francisco Vila :
>> have you seen the facsimiles in the message
>> http://lists.gnu.org/archive/html/lilypond-devel/2010-12/msg00398.html
>> ?
>
> The attached file in that message must be a joke!
aargh, my bad. as I look at it now,
it's actually a gzip-compressed tar archive,
you can
>> > * Use the left-stemmed longa in ligatures.
>
>> exactly what is this last one?
>
> When note_shape is MLP_LONGA and the direction of the stem is UP, then
> the left-stemmed longa is used.
oh, indeed. I must have messed up my build, now I see it.
unfortunately this is bad.
look at the first r
hi Bertrand,
> Ok Pal, I removed the left-stemmed longa.
thanks, mensural-ligatures.ly is now ok.
p
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
> Passes make and new reg test differences (look ok) attached here
in all four .png's I can see empty rectangles instead of longae.
p
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
hi Bertrand,
> The new mensural style introduced with commit
> 0dcc93c0a5a97d048db2f7631966f41ae0059ab5 created some ugliness's in
> mensural ligatures.
which commit is the patch supposed to apply to?
I couldn't apply it to my HEAD
f8a4491c571dc57c87aec33dc8e34c436e222537;
having applied it to 0d
2013/6/15 Phil Holmes :
> I'm setting a piece of late 16th century music (it's in Musica Transalpina),
> and at this time notes and rests tended to occupy a space determined by
> their fitment on the page, rather than their note value. I've read the
> section of the NR on proportional spacing, whi
hi David,
> The probability that some envelope-finding code dropped into LilyPond
> by a typical LilyPond contributor is close to the quality of somebody
> who wrote a Phd thesis focused around the topic is slim.
I did write a Phd thesis not very far from that. the time I can spend
on LilyPond
> pass the debug flags to the configure call.
> CXXFLAGS=-ggdb3 ./configure
> you can also build a profiling build throught the same mechanism.
>
> The --with-debug or like switches that a configure call supports should
> refer to
> extra debugging checks in the code switched on.
even better: con
> Well, I don't know without further digging. However, there is a notation
> style called black mensural, and it seems only logical that Lilypond should
> support this using the available glyphs.
sorry for the confusion. I introduced black note heads to support
coloratio in white mensural notati
> I'm occasionally repondering the barline |: :| issue and I want to know
> if anybody's music typesetting theory text or private music library has
> examples of repeats starting and/or ending in mid-bar. I seem to
> remember that there is some weakened double bar in use for that,
> something like
hi Janek,
2013/12/11 Janek Warchoł :
> 2013/12/10 :
>>> However, if you don't mind, i'd prefer to leave it as is - i have
>>> _already_ spent about 4 hours cleaning up and rebasing commits to make
>>> them somewhat ordered for review, and i'm quite tired.
>>
>>
>> I do mind. this is not the sort
>> if requested, I can either update dev/janek/metafont-cleanup
>> or push as a new branch.
>
> Please do so!
pushed as
dev/benko/metafont-cleanup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-dev
2014/1/1 :
>
> Janek, when people start with `git clone` do they also get a staging
> branch that tracks the one on savannah?
> I think we still want at least one mention of how to set up a 'staging'
> branch to track origin/staging,
> git checkout --track -b staging origin/staging
you can set
hi,
> I've had to reinstall LilyDev, and I'm no longer able to see all of the
> remote branches. When I run
>
> git branch -a
>
> I simply see:
>
> dev/local_working
> master
> remotes/origin/master
you may have cloned only the master branch. try
git fetch --all
p
hi Paul,
> I submitted a patch and I am sorry to say that somehow it was added to the
> wrong issue:
> https://codereview.appspot.com/54050043
>
> And a new issue (with the wrong title and content) was created in the google
> code tracker:
> https://code.google.com/p/lilypond/issues/detail?id=3883
101 - 200 of 226 matches
Mail list logo
