2009/7/19 Mark Polesky :
> I attached the updated patch. Okay to apply?
Nearly there...
+ (note-columns ,ly:grob-array? "A list of @code{NoteColumn} grobs.")
"An array of @code{NoteColumn} grobs.")
Regards,
Neil
___
lilypond-devel mailing list
2009/7/19 Mark Polesky :
> Are these two patches okay to apply?
LGTM.
> Starting on line 845 in define-grob-properties.scm, there is a group
> labeled "grobs & grob arrays", and of the 60 or so properties there, all
> of them have type ly:grob or ly:grob-array, except the following nine.
> Should
2009/7/15 Carl Sorensen :
> I'm not sure I understand why you think it should it be in input/new instead
> of just being in the docs. It doesn't use \set or \override. It explains
> the use of a LilyPond command. That's why I thought it should be an inline
> snippet.
It's positioned in the mid
2009/5/30 Joe Neeman :
> The sanest behaviour IMO is the behaviour of your current patch, but
> with a different meaning for 'padding. I can see two ways to do this:
> the quick&dirty way to get this is to replace
> instrument-name::calc-combined-delimiters-offset with
> instrument-name::calc-min-
2009/4/25 Neil Puttock :
> 2009/4/23 Jan Nieuwenhuizen :
>> I don't really care about that, but it would be nice to split-out
>> the (find-brace lambda to a generic function.
>
> OK, I'll farm it out to lily-library.scm and upload a new patch.
A new pat
2009/7/14 Carl Sorensen :
> It has cleaned up all of the issues that Neil identified, with the exception
> of default autobeaming for 3/4 time. I never got any concurrence for
> setting it back to (3), so it's left at (1 1 1).
I think (3) is preferable, at least for quavers.
The Baerenreiter Ba
2009/7/14 Carl Sorensen :
> Can we get something in the CG about this problem, and how to run
> update-snippets.py to fix things, or at least a statement about the easiest
> way to solve the problem?
It's already mentioned in CG (in passing), but I got the impression
when I stumbled across it for
2009/7/12 Carl Sorensen :
> I don't know. I didn't write displayLilyMusic; that was Nicolas IIRC. I do
> know that \time 3/4 executes those functions. It's really easy to go
> forward in the parse tree (i.e. from \time 3/4 to \set Timing), but I
> don't know any way to reliably go in revers
2009/7/14 Mark Polesky :
> 1) are the results of this technique undefined? Was it just luck
> that these worked?
Of course not. You're just accessing the accidental indirectly.
Perhaps we should amend the documentation for \tweak: it can't be used
to modify stems, beams or accidentals *direct
2009/7/13 Maximilian Albert :
> Thanks a lot! So does this close issue 685?
Yes.
> What's the status about
> .log files being created on Windows mentioned there?
Assuming this is a feature Windows users would like, it should be
logged as a new issue (low priority enhancement I'd imagine).
Rega
2009/7/10 Maximilian Albert :
> OK, thanks. Now the docs compiled fine and I could check that the
> result of my patch is as intended. Any further comments or are they
> ready to be applied?
Thanks, they're both applied.
Regards,
Neil
___
lilypond-de
2009/7/12 Patrick McCarty :
> Did you do
>
> git rebase --abort
>
> before trying to apply his earlier patch?
Of course. :) I just got confused with different patches and applied
the wrong one.
Regards,
Neil
___
lilypond-devel mailing list
lilypond
2009/7/12 Mark Polesky :
> Please double-check once more and apply.
For some reason, I can't apply it.
Applying: Docs: NR B.6 The Feta font: Organize glyph list.
/home/neil/lilypond/.git/rebase-apply/patch:15: trailing whitespace.
/home/neil/lilypond/.git/rebase-apply/patch:16: trailing whitesp
2009/7/11 Carl Sorensen :
> Does one then go and remove the snippet reference from the translated .itely
> files as well?
This is what I've always done, otherwise you're left with broken documentation.
Regards,
Neil
___
lilypond-devel mailing list
li
2009/7/12 Mark Polesky :
> Is it ready to apply?
Looks fine.
If I may sugget one refinement: use the quote environment (it produces
nicer looking examples in html).
@lilypond[quote]
Regards,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.o
2009/7/12 Carl Sorensen :
> I've created a second patch set with the whitespace removed (along with
> automatic removal of whitespace from the lines of the files that weren't
> part of the patch).
Brilliant work, Carl!
I'll comment on individual issues in Rietveld shortly.
I notice you've chang
2009/7/9 Maximilian Albert :
> 2009/7/9 Jan Nieuwenhuizen :
>> On do, 2009-07-09 at 21:41 +0900, Maximilian Albert wrote:
>>> Hi,
>>>
>>> while running the regtests I spotted a warning about the use of the
>>> deprecated md5 module in scripts/lilypond-book.py. Attached is a patch
>>> which replaces
2009/7/10 Mark Polesky :
> I was having trouble finding glyphs in NR B.6, so I reorganized
> things. I'm not saying I used the best approach, but I think this
> would be an improvement. Any comments or suggestions? A better
> approach? See the attached file.
I like it. Though it sacrifices a bit
2009/7/10 Carl Sorensen :
> I'll take a snippet that's in the docs (not one that's included as a file),
> copy it to a .ly file, wrap it in \relative c''{}, and everything works
> fine.
>
> But when I compile the docs with make doc, the snippet doesn't work.
Can you explain in more detail how it
2009/7/9 Maximilian Albert :
> You can find them here, along with the error message (at the bottom):
> http://pastebin.com/m2bcb5c37
I've just got the same error. It's caused by Graham's essay makefile hacking.
Unfortunately I don't know how to fix it apart from reverting the whole patch.
Rega
2009/6/29 Graham Percival :
> On Mon, Jun 29, 2009 at 04:41:22PM +0100, Neil Puttock wrote:
>> Can you make me a project member on the bug tracker? It will save
>> time and hassle if I can do the tagging myself once I've ported each
>> bugfix.
>
> Certainly!
2009/6/29 Mark Polesky :
> 1) Did I make any mistakes?
These are so deprecated, they don't exist (you've picked them up from
the Changelog):
ly:paper-def?
ly:verbose?
> 3) when you write this:
> > None here, as long as you automate it (perhaps use a markup
> > command to extract and prettif
2009/6/28 Mark Polesky :
> two questions:
>
> 0) should I redo this? http://codereview.appspot.com/83042/show
Yes please, at least to remove your comment concerning the duplication
(line 1613).
You might as well leave the duplicated 'direction setting for the moment.
> 1) I'd like to have all
2009/6/28 Mark Polesky :
> Please apply.
Thanks, applied.
Regards,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
2009/6/24 Graham Percival :
> If you're willing, then great! With 2.14 being delayed by another
> month, it probably *is* a good idea to get another 2.12 release
> out there that includes more than gcc-4.4 fixes.
Ok, I'll start work on it in a few days' time once I've tidied up the
loose ends wi
2009/6/28 Mark Polesky :
> does that affect what you said here (regarding define-grobs.scm)?
Possibly; it may well be that ly:script-interface::calc-direction is
the right callback in both cases if changes are made which result in
removal of the error message I reported.
Regards,
Neil
2009/6/25 Patrick McCarty :
> Was this taken care of?
>
> http://lists.gnu.org/archive/html/lilypond-devel/2008-05/msg00122.html
No.
> I don't know what callbacks needed to be changed, so I figured I would ask.
Neither do I.
Setting a default direction for DynamicText works (in the same way as
2009/6/24 Carl D. Sorensen :
> But if we're eliminating Dynamic_engraver, all the functionality it has will
> be going away anyway. So I don't think there's any loss in changing the
> name.
Fair enough; I guess I've just got used to the name New_dynamic_engraver. :)
Regards,
Neil
2009/6/24 Carl D. Sorensen :
> Shouldn't we do this by eliminating Dynamic_engraver and renaming
> New_dynamic_engraver to Dynamic_engraver?
I'm not sure, since New_dynamic_engraver doesn't have all the
functionality of Dynamic_engraver (though it would be easy enough to
have a convert rule which
2009/6/23 Graham Percival :
> Once I've made one or two "official" 2.13 release, I'm
> quite happy to make 2.12.4 with those building-on-gcc-4.4 fixes.
If you're thinking of doing this, it would be good to backport other
bugfixes from 2.13. I'll happily volunteer to do this if you think
it's a g
2009/6/21 Mark Polesky :
>
> 1.2.3 Displaying rhythms (Automatic note splitting) says:
>
> The Completion_heads_engraver only affects notes; it does not
> split rests.
>
> Is there a stumbling block? How easily could this be changed? I'm
> finding myself in situations where splitting rests would co
Hi everybody,
Since the Dynamic_engraver is no longer used due to being replaced
just over a year ago, I'd like to remove it completely.
Any objections?
Regards,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman
2009/6/23 Graham Percival :
> I think I've managed to build with GUB. linux-x86 and darwin-x86
> builds work ok for me. If somebody can test the mingw version,
> then I'll try making this an official release on lilypond.org
The mingw version works for me, though it still suffers from font lookup
2009/6/20 Trevor Daniels :
> Typing "guile" works fine for me in git bash, but in the command
> prompt window under Vista I get
>
> ERROR: In procedure primitive-load-path
> ERROR: Unable to find file "ice-9/boot-9.scm" in load path
I get the same error under XP, so it's quite possible I'm confus
2009/6/20 Patrick McCarty :
> The combined patches are here:
>
> http://codereview.appspot.com/83042/show
Thank you.
I can already sense Mark's next task: sorting the `interfaces' field. :)
Regards,
Neil
___
lilypond-devel mailing list
lilypond-deve
2009/6/19 Mark Polesky :
>
>> One curious thing I've noticed when looking over this
>> is in the definition for Script:
>>
>> line 1477: ;; don't set direction here: it breaks staccato.
>>
>> ...then 9 lines later, direction is set...
>>
>> line 1486: (direction . ,ly:script-interface::calc-dir
2009/6/18 Patrick McCarty :
> Okay, thanks for the guidance. Attached is a revised patch.
Cheers, it's applied.
Regards,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
2009/6/19 Graham Percival :
> If you'd like to add f for consistency's sake, I'm happy to
> commit it -- but please also add a comment to dynamic-init that we
> really don't want more than 5 letters. :)
The curious thing about this is that there's already an entry for
f in absolute-volum
2009/6/19 Mark Polesky :
>
> This may be totally obvious to everyone here, but Windows users
> can't just run guile without running LilyPond (I'm thinking for
> users who are working on learning scheme). At least not to my
> knowledge.
When I was using Windows exclusively, I used to open a command
2009/6/19 Patrick McCarty :
> I ran the test suite with Mark's patches, and everything looks fine here.
I'd like to look at the patches, but they're obviously over the size
limit for attachments. :)
Can somebody post them on Rietveld so we can all have a look at them?
Regards,
Neil
__
2009/6/17 Mark Polesky :
> do you think remove-accidental would be more semantically
> accurate than hide-accidental?
Not particularly, since that implies that it exists in the first place.
> I'm thinking that \hideNotes
> still leaves space where the notes would be, but this
> function doesn't
2009/6/17 Han-Wen Nienhuys :
> I think this can be neater. By tracking the 'cause property
> backwards, this could simply be a grob property callback, and the C++
> does not need to touch the
> 'dot-count property.
We already have the callback, as I pointed out in the other thread:
dots::calc-dot
t
> possible? Would it be difficult to implement?
It's quite simple to do.
Attached is a patch which uses an ampersand to hide accidentals.
Regards,
Neil
From 86eeeb51725d3f1752c0a75b7e024a93dca03927 Mon Sep 17 00:00:00 2001
From: Neil Puttock
Date: Tue, 16 Jun 2009 22:39:43 +0100
Subject
2009/6/16 Mark Polesky :
> But neither of these do anything either:
> { \override Dots #'dot-count = #0 c''4. }
> { \override Dots #'dot-count = #3 c''4. }
That's because the Dots_engraver overrides 'dot-count, which means
your override is ignored:
46 d->set_property ("dot-count", scm_fr
2009/6/8 Francisco Vila :
> Great! Let's do it, could you send a patch? Forwarding to -devel.
Sure, here's a patch using my first suggestion:
>From b387a453c08b4f8618c51a0b48abee87d7d62644 Mon Sep 17 00:00:00 2001
From: Neil Puttock
Date: Wed, 10 Jun 2009 23:47:25 +0100
2009/6/7 Graham Percival :
> Hey, Jan was just complaining about patches doing too much, and I
> promised to crack down. If we start complaining about patches
> that are too granular, we'll send mixed messages. :)
I was reminded of Jan's post as I replied to Mark, but I thought it
would be OK s
2009/6/7 Graham Percival :
> I did:
> git tag release/2.13.1 0ac...86a
> and I can see the tag in my own gitk, but when I push, it doesn't
> update the list of tags on the web-git page. Anybody know what's
> wrong?
Did you do `git push --tags' too?
Regards,
Neil
_
2009/6/7 Mark Polesky :
> These overrides in the first example should clearly be \overrideProperty
>
> \override NonMusicalPaperColumn
> #'line-break-system-details #'((alignment-offsets . (0 -15)))
>
> \override NonMusicalPaperColumn
> #'line-break-system-details #'((X-offset . 20) (Y-offset . 4
2009/6/4 Patrick McCarty :
> The "print-book-with" procedure is pretty specialized, but I don't see
> any harm in making it public.
It's a helper function for print-book-with-defaults and
print-book-with-defaults-as-systems, so there's no need to make it
public.
-(define (split-at-predicate pred
2009/6/7 Mark Polesky :
> Reinhold Kainhofer
> Better detection which characters need to be quoted...
> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=0ac32e91fab38b860ad951b8f0cd4700f79ba86a
This is the release commit. If you look at the regression test
results, you'll see it lis
2009/6/7 Mark Polesky :
>
> List choices in break-align-symbols docstring.
> http://lists.gnu.org/archive/html/lilypond-devel/2009-05/msg00475.html
LGTM.
Will apply once I've finished docs compilation.
> Make some local functions public.
> http://lists.gnu.org/archive/html/lilypond-devel/2009-05
2009/6/4 Patrick McCarty :
> Any comments for this revised patch? The only things I changed were
> the warning messages.
Reinhold's suggestion for the message is an improvement, so I'm happy
to apply the revised patch.
Regards,
Neil
___
lilypond-dev
2009/6/5 Graham Percival :
> On Thu, Jun 04, 2009 at 07:46:10PM -0500, Jonathan Kulp wrote:
>> I read the diff for CG when it came in this morning and the LSR stuff
>> looks good to me. If you want, we could also include the script I wrote
>> for checking all the snippets at once. Carl suggested th
2009/5/29 Han-Wen Nienhuys :
> LGTM
Applied.
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
2009/5/25 Mark Polesky :
> Here's a proposal:
>
> Here are two generic functions that could be incorporated into IR
> 4 "Scheme functions" (though if C++ is required, someone else
> would have to help).
C++ would be required, though these aren't suitable candidates for
export since they don't do
2009/5/28 Patrick McCarty :
> Attached is a revised patch.
That was quick. :)
LGTM.
+ warning (_f ("the `%s' backend does not support -dprint-pages",
+get_output_backend_name ()));
+ warning (_f ("the `%s' backend does not support -dpreview",
+
2009/5/28 Mark Polesky :
> okay.
Thanks, applied.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
2009/5/24 Joe Neeman :
> Fair enough, but I don't think 'padding has the right meaning here.
> Ideally, 'padding should be the smallest distance between an
> InstrumentName and the SystemStartXXX to its right. Here, it's the
> distance between the rightmost InstrumentName and the leftmost
> System
2009/5/27 Joe Neeman :
> On Wed, 2009-05-27 at 02:17 -0700, Mark Polesky wrote:
>> line 408 of define-grobs.scm lists "staff" in a break-align-orders
>> vector. Is that a typo?
>
> I think so.
>
>> line 49 of lsr/creating-simultaneous-rehearsal-marks.ly reads:
>> \once \override Score.RehearsalMark
2009/5/24 Carl D. Sorensen :
> On a more general note, do you have any suggestions for how to check
> convert-ly rules? For code, we have regression tests. For convert-ly, as
> far as I know, we have nothing. Should we be establishing convert-ly
> regression tests?
I'm not sure how that would
2009/5/25 Andrew Hawryluk :
> Yes, I'll take a look at it. Thanks, Neil for catching those!
No problem.
I'm sorry I didn't respond earlier; though I'd taken a cursory look at
the patch (and noticed the backquote issue), I didn't expect it to be
committed so soon.
Regards,
Neil
___
2009/5/24 Carl D. Sorensen :
> Thanks, Applied.
Unfortunately, there are two serious flaws here:
- keySignature alists which aren't backquoted (e.g., the example in
the bug tracker) will be ignored
- entries of the form (notename . alteration) are mangled:
\set Staff.keySignature = #'((0 . 2)
2009/5/23 Joe Neeman :
> If I understand this correctly, you're suggesting that we pad each
> instrument name according to the largest (wrt X-extent) SystemStartXXX.
That's basically it, though the extent would be that of the greatest
number of stacked delimiters: for example, in the Haydn snippe
eeply nested
stave.
I've attached a proof of concept patch together with an image
demonstrating left-, centre- and right-aligned instrument names.
Regards,
Neil
<>From 6bfeefe1e0f84b39039bf893195eebeca08681c1 Mon Sep 17 00:00:00 2001
From: Neil Puttock
Date: Fri, 22 May 2009 23:40:25 +0100
2009/5/16 Graham Percival :
> In the large "DOC: Makefile" thread that nobody new is going to
> read, there was a proposal to use .ily to indicate "setup"
> lilypond files.
>
> I quite like this suggestion, so I'm asking somebody to take the
> next step: integrate this with lilypond.
It'll be quit
2009/5/18 Jonathan Kulp :
> Good to hear. Do you have push access? If not, then would someone else
> mind pushing it for me? Thanks,
Happy to oblige. :)
Regards,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mail
2009/5/15 Kieren MacMillan :
> Hi Neil,
>
> Thanks for the help.
>
>> Tricky without another voice, since there's only one stem for all the
>> noteheads. You can change the length of a stem by overriding 'length,
>> but you'd need to be careful about stem direction because negative
>> values will b
2009/5/15 Kieren MacMillan :
> I'm trying to come up with a Scheme function to generate string harmonics
> automatically.
Why on earth would you want to do that. ;)
You might like to take a look at Valentin's function here (though it
uses separate voices):
http://repo.or.cz/w/opera_libre.git?a=
2009/5/12 Carl D. Sorensen :
> I think I need to create chord_name_ in two different places, because in one
> place the event is notes_[0] (if I have a chord), and in the other it's
> rest_event_ (if I have a rest). But all the other stuff can avoid
> duplication, I think.
You could use the cond
2009/5/10 Patrick McCarty :
> Yes, I suppose that is a better idea. Attached is a revised patch.
Thanks, it's applied.
Regards,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
2009/5/10 Kieren MacMillan :
> Hey, devs!
>
> While helping a newbie on -user, I noticed that ignoreMelismata doesn't
> *actually* ignore melismas fully: in the attached example, you'll note that
> the "three" syllable is *left-aligned*, as it would be if it were
> *observing* melismata. Does anyon
2009/5/7 Patrick McCarty :
> Does anyone have any comments about this patch?
The SVG source is much easier to read. :)
I don't know anything about SVG, so I can only comment on the scheme code:
You're compiling the regexp each time the function's called; would it
be better to define it outside
2009/5/9 Carl D. Sorensen :
> Similar to the Bass_Figure_engraver, I don't think I want to use
> ASSIGN_EVENT_ONCE (), because even if I have polyphonic rests, I just want
> one N.C. symbol.
<< { r4 } { r8 r } >>
will result in two no-chord symbols unless you assign it once.
> No, I'm proposin
2009/5/9 Carl D. Sorensen :
> Over the past few months, several people have asked for a "N.C." notation to
> be part of the ChordNames context.
>
> It occurred to me that using r to generate a "N.C." would be logically
> consistent -- the music gets a rest, the chord name gets a "N.C.". And if a
>
2009/5/7 Reinhold Kainhofer :
> 4) cresc = #(make-music 'CrescendoEvent 'span-direction START 'spanner-text
> "cresc.")
I favour this version since its the least ambiguous; there's no risk
of a user trying to make e.g. a 'CrescendoEvent with
'descrescendo-text.
> In particular, the question is
2009/5/1 Patrick McCarty :
> It's a judgment call, but I think you would be the best candidate for
> fixing it, since you have recently looked at this code.
Hehe. :)
The less diplomatic answer:
You should fix it because your patch broke ly:error.
You could of course use an extra scm_is_pair to
2009/5/1 Carl D. Sorensen :
>
>
>
> On 4/26/09 9:31 AM, "Neil Puttock" wrote:
>
>> 2009/4/26 Trevor Daniels :
>>
>>> Just to recap, the advantage of \override over \set is that previously
>>> overridden values can be recovered by \revert b
2009/4/30 Werner LEMBERG :
> Interestingly,
>
> lilypond -dbackend=eps lily-7d242e8d.ly
>
> works just fine.
Looks like you were trying to run the snippet with the lilypond-book
preamble included.
You should get the following error message,
The PostScript backend does not support the
system-by
2009/4/26 Trevor Daniels :
> Just to recap, the advantage of \override over \set is that previously
> overridden values can be recovered by \revert because they are
> pushed onto a stack, whereas \unset simply restores the original
> default value. Is that right?
Yes.
The problem with context p
2009/4/25 Carl D. Sorensen :
> There is a binary search routine for scheme vectors in
> lily/quote-iterator.cc. Would it preferable to export that function call
> and use it?
I don't know... is there a way of using such an exported function with
other scheme types?
Regards,
Neil
_
2009/4/24 Mats Bengtsson :
> I haven't looked at your patch or the implementation, but suddenly
> remembered about
> http://lists.gnu.org/archive/html/lilypond-devel/2008-11/msg00405.html
> which seems to indicate that a binary search was already done.
Yes, it's in System_start_delimiter::staff_br
2009/4/23 Jan Nieuwenhuizen :
> Op donderdag 23-04-2009 om 07:19 uur [tijdzone +0200], schreef Werner
> LEMBERG:
>
>> I'm not a good lisp programmer, but isn't the standard method for
>> searching like that to not use a loop but recursive calls?
>
> I don't really care about that, but it would be n
2009/4/23 Werner LEMBERG :
>
>>> Please review this patch here:
>>>
>>> http://codereview.appspot.com/8874/show
>>
>> Looks good!
>
> I'm not a good lisp programmer, but isn't the standard method for
> searching like that to not use a loop but recursive calls? It doesn't
> really matter, but Han-W
2009/4/25 Carl D. Sorensen :
>
>
>
> On 4/25/09 8:24 AM, "Neil Puttock" wrote:
>
>> 2009/4/22 Carl D. Sorensen :
>>
>>> Does this help clarify what I'm thinking?
>>
>> Yes, thank you.
>>
>> To be honest, I'm no
2009/4/22 Carl D. Sorensen :
> Does this help clarify what I'm thinking?
Yes, thank you.
To be honest, I'm not convinced by the idea of using a fake grob just
for the convenience of easy overriding and reverting.
Regards,
Neil
___
lilypond-devel mai
2009/4/21 Robert Memering :
> I have come across several cases with non-melismatic ligatures in
> renaissance polyphony.
> Indeed, I am afraid that changing the default behaviour would break several
> of my scores.
This wouldn't be an issue since it would be implemented in the same
way as current
2009/4/21 Carl D. Sorensen :
> I haven't checked yet for beam subdividing (I will need to, I know), but for
> autobeaming, the work is done in a scheme callback, where the context is
> available.
There is no callback, otherwise get_property ("autoBeamCheck") would
automatically return #t or #f; i
Hi,
Please review this patch here:
http://codereview.appspot.com/8874/show
I've revised the \left-brace command extensively so it uses a binary
search to find the closest matching fetaBrace.
You might notice that the braces produced are slightly smaller than
the equivalent SystemStartBrace grob
2009/4/15 Carl D. Sorensen :
> So why can't we define an AutoBeamPlaceHolder grob description (defined in
> scm/define-grobs.scm), which has an auto-beam-setting-interface (defined in
> scm/define-grob-interfaces.scm)? It would have no engraver, but I can't see
> that having an engraver is necess
2009/4/19 Carl D. Sorensen :
> Perhaps, but I think it's a good idea to actually test how the snippet shows
> up in the docs, because there's documentation, not just LilyPond, in the
> snippet. Is there another way to do this that's easier than making the
> slight change to the snippet and copyin
2009/4/18 Carl D. Sorensen :
>
> I think something like the following needs to go in the CG under
> Documentation Work somewhere -- Probably after TWEAKS in section 3.4.
>
> "If a new snippet created for documentation purposes will compile in
> the current LSR version, the snippet should be added t
2009/4/18 Carl D. Sorensen :
>
>
>
> On 4/17/09 1:34 PM, "n.putt...@gmail.com" wrote:
>> http://codereview.appspot.com/41099/diff/1021/52
>> File Documentation/user/expressive.itely (right):
>>
>> http://codereview.appspot.com/41099/diff/1021/52#newcode634
>> Line 634: @lilypondfile[verbatim,lily
2009/4/17 Carl D. Sorensen :
> Does anybody *want* constant-thickness slurs or ties? I thought that
> variable thickness was clearly better. I think that keeping inferior output
> to avoid conversion problems is not a good decision. I'd rather force the
> user to make a simple manual change and
2009/4/17 Carl Sorensen :
> Carl D. Sorensen byu.edu> writes:
>
>>
>> Please review my patch for dashed slurs on rietveld:
>>
>> http://codereview.appspot.com/40122/show
>>
>
> I've revised my patch to eliminate some debug garbage that was
> left in the files, and to make the bezier subdivide rout
2009/4/14 Carl D. Sorensen :
> It seems to me to be the same to set an alist for AutoBeamSetting. When
> it's time to do the auto-beam calculations, the code can ask the context for
> the property setting.
Fine, but you can't make it appear to be a grob; it must be
autoBeamSetting as a context p
2009/4/14 Carl D. Sorensen :
>
>
>
> On 4/14/09 1:39 AM, "Mats Bengtsson" wrote:
>
>> Have you forgot about the most basic difference between a context
>> property and a grob property?
>> All grob property are connected to a specific graphical object, so the
>> syntax is
>> \override Object #'prop
2009/4/11 Mark Polesky :
>
> Neil Puttock wrote:
>> > Why does Slur have an 'avoid-slur property?
>> So they avoid phrasing slurs.
>>
>> \relative c' {
>> \override Slur #'avoid-slur = #'outside
>> c\( d( e) f\)
>> }
2009/4/12 Patrick McCarty :
> On Sun, Apr 12, 2009 at 12:28:06AM +0200, Reinhold Kainhofer wrote:
>>
>> On Samstag, 11. April 2009 20:33:47 n.putt...@gmail.com wrote:
>>
>> > You'd
>> > need a method which does the reverse of camel_case_to_lisp_identifier ()
>> > so that the events would be convert
2009/4/11 Mark Polesky :
> 'avoid-slur proposals:
>
> 1. remove 'avoid-slur from Slur properties
>
> Why does Slur have an 'avoid-slur property?
So they avoid phrasing slurs.
> Can anyone give an example where the command
> \override Slur #'avoid-slur = #
> has an effect?
\relative c' {
Hi,
Currently left-broken line spanners and hairpins are removed
automatically if they end on the first note. Though this is usually
appropriate for trills, glissandi and hairpins, there are situations
where it would be useful to override this default behaviour, for
example when using text spans.
701 - 800 of 1080 matches
Mail list logo
