Le mardi 21 juillet 2009 à 23:57 -0700, Graham Percival a écrit :
> I would personally remove the web/, and have things like
> lilypond.org/introduction.html
> lilypond.org/doc/v2.x/
> lilypond.org/download/
> lilypond.org/tiny_examples.html
> along with whatever redirects are desirable.
I
As the changes involved by the new web site are quite large and
invasive, I try to give steps so you are not too surprised by what's
going on with dozens of files suddenly moved or temporarily broken HTML
links. Please report any breakage in case I haven't explicitly mentioned
it in a commit (this
In NR 2.2.1 Changing staff automatically, it says this:
Chords will not be split across the staves; they will be assigned
to a staff based on the first note named in the chord construct.
http://kainhofer.com/~lilypond/Documentation/user/lilypond/Common-notation-for-keyboards.html#Changing-staff-a
> I've also attached 2 png's to demonstrate the difference: the first
> one (current.png) was compiled with the current autochange.scm and
> the second one (revised.png) was compiled with my revised patch.
> You can look at the test file below to see how it is set up.
The results looks fine for m
Fingers crossed.
2009/7/22 John Mandereau :
> As the changes involved by the new web site are quite large and
> invasive, I try to give steps so you are not too surprised by what's
> going on with dozens of files suddenly moved or temporarily broken HTML
> links. Please report any breakage in case
Mark Polesky writes:
> Anyway, I think that it would make a lot more sense if the staff were
> determined by the "average" pitch of the chord.
I don't think so. The purpose of staff changes is to avoid help lines.
In particular where they would require systems to be paced further
apart. For th
At 10:50 on 22 Jul 2009, David Kastrup wrote:
> Mark Polesky writes:
>
> > Anyway, I think that it would make a lot more sense if the staff
> > were determined by the "average" pitch of the chord.
>
> I don't think so. The purpose of staff changes is to avoid help
> lines. In particular where t
>> Anyway, I think that it would make a lot more sense if the staff
>> were determined by the "average" pitch of the chord.
>
> I don't think so. The purpose of staff changes is to avoid help
> lines.
Perhaps it makes sense to provide different `modes', depending on the
purpose.
Werner
2009/7/21 Werner :
> \midi {
> \context {
> \Score
> % harmonies = ##f
> % (output all voices but no harmonies from chordNames!)
> }
> }
There's already a way to do it. Try something such as
\midi {
\context {
\type "Performer_group"
\name ChordNames
Mark Polesky wrote Wednesday, July 22, 2009 8:32 AM
In NR 2.2.1 Changing staff automatically, it says this:
Chords will not be split across the staves; they will be assigned
to a staff based on the first note named in the chord construct.
http://kainhofer.com/~lilypond/Documentation/user/lily
On Wed, Jul 22, 2009, Trevor Daniels said:
>> Anyway, I think that it would make a lot more sense if the staff
>> were determined by the "average" pitch of the chord. And, I think
>> I've solved this in the attached patch.
What would make the most sense is to consider the range of the intended
i
Wow. Thanks for all the replies. I'll answer one at a time, all
below.
David Kastrup wrote:
> I don't think so. The purpose of staff changes is to avoid help
> lines. In particular where they would require systems to be
> paced further apart. For this, the average is irrelevant, only
> the tota
writes:
> On Wed, Jul 22, 2009, Trevor Daniels said:
>
>>> Anyway, I think that it would make a lot more sense if the staff
>>> were determined by the "average" pitch of the chord. And, I think
>>> I've solved this in the attached patch.
>
> What would make the most sense is to consider the rang
Hello all,
Like many Lilyponders, I break down my code into variables, e.g.
global (for time signature changes, etc.), notes, dynamics, etc. The
main irritation with this (IMO) is that each variable requires a
complete set of skips in order to keep the timing accurate.
Would it be technic
Kieren MacMillan wrote:
> Like many Lilyponders, I break down my code into variables, e.g.
> global (for time signature changes, etc.), notes, dynamics, etc.
> The main irritation with this (IMO) is that each variable
> requires a complete set of skips in order to keep the timing
> accurate.
>
> W
Hi Mark,
Have you tried using the \tag command?
http://lilypond.org/doc/v2.12/Documentation/user/lilypond/Different-
editions-from-one-source#Using-tags
Certainly I've used \tag for filtering content, but I don't
understand how \tag could help with the problem I'm describing...
could you
I'm trying to avoid code duplication as I work with fixing the beam-grouping
code.
I'm defining some procedures that can be called both from c++ and scheme to
get grouping rules from the context property.
In order to call from scheme, I need to have context be a smob.
In my call from c++, I have
(creating a new thread to separate the clef stuff from the staff
stuff)
David Kastrup wrote:
> I'll agree that any optionally usable clefs should be specified
> in advance. A "clef" in this respect may also consist of "8va"
> notations. There are instrument-dependent "thresholds of pain"
> invol
Carl Sorensen byu.edu> writes:
>
> SCM my_context = smob_context(Context *context)
>
> Does this function exist?
Sorry for the noise -- I found
context->self-scm()
which does what I need.
Thanks,
Carl
___
lilypond-devel mailing list
lilypon
On wo, 2009-07-22 at 10:56 -0600, Carl Sorensen wrote:
> Context *myctx = unsmob_context(SCM context)
>
> But I haven't been able to find the inverse:
>
> SCM my_context = smob_context(Context *context)
SCM c = context->self_scm () ?
Jan.
--
Jan Nieuwenhuizen | GNU LilyPond - The music type
On Wed, Jul 22, 2009 at 9:05 AM, Kieren
MacMillan wrote:
> Hello all,
>
> Like many Lilyponders, I break down my code into variables, e.g. global (for
> time signature changes, etc.), notes, dynamics, etc. The main irritation
> with this (IMO) is that each variable requires a complete set of skips
Reviewers: Neil Puttock, joeneeman,
Message:
OK, I've responded to Joe's comments.
I've created a new file lily/beam-scheme.cc, and put c++ and scheme
callable routines in it. Then I've used those calls from auto-beam.scm,
measure-grouping-engraver.cc, and beaming-pattern.cc. I also added a
ne
2009/7/22 Mark Polesky :
> These ideas sound ambitious to me, but should anyone want to try
> implementing them in the future, s/he can consult this post.
I can add whatever will not be implemented soon as (a) feature
request(s) in the tracker – possibly including the autochange patch,
since it s
2009/7/22 Jay Anderson :
> In any case I think anchors could be very useful for a variety of purposes.
Yaay! For one, it would simply change my life :-)
I'm not sure if it is at all possible without major changes to the way
Lily currently works though. I'll wait a few days to see where this
discu
Hello all,
Jay's "\addTo" twist gave me a (naive) thought...
If \addTo simply constructed (e.g., appended to) an ordered list of
moment-event (moment-grob?) pairs, couldn't the parser simply grab
the one(s) it needed at any given moment?
Yaay! For one, it would simply change my life :-)
2009/7/21 Mark Polesky :
> Here are four more code-cleanup patches.
>
> Okay to apply?
LGTM apart from a few tiny details which have caught my eye:
(0001-define-grobs.scm-Sort-interfaces.patch)
@@ -1871,10 +1870,10 @@
(X-offset . ,ly:self-alignment-interface::x-aligned-on-self)
(
Neil Puttock wrote:
> LGTM apart from a few tiny details which have caught my eye:
>
> (0001-define-grobs.scm-Sort-interfaces.patch)
> (0003-define-music-properties.scm-Sort-all-music-propertie.patch)
> (0004-define-music-types.scm-Sort-music-descriptions-alist.patch)
Neil,
Am I to assume that
2009/7/22 Mark Polesky :
> Am I to assume that patch 0002 is error-free? It's not like you
> to accidentally skip over something, but I had to ask!
Yep, looks fine.
Regards,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu
I think this is pretty much ready to commit
http://codereview.appspot.com/88155/diff/3101/4032
File lily/beam-scheme.cc (right):
http://codereview.appspot.com/88155/diff/3101/4032#newcode2
Line 2: beam-scheme.cc -- Retrieving beam settings
could you call this beam-grouping-scheme.cc or somethin
I've tweaked the autochange code a little more and I've been able
to make some of the improvements suggested. It's still under
construction, but I'm posting it so you guys can play with it.
The easiest way to test it would be to just save the
autochange_revised.scm and autochange.ly attachments in
http://codereview.appspot.com/88155/diff/3101/4027
File input/new/grouping-beats.ly (right):
http://codereview.appspot.com/88155/diff/3101/4027#newcode7
Line 7: Beaming patterns may be altered with the @code{beatGrouping}
property:
new texidoc using \overrideBeamSettings
http://codereview.appsp
2009/7/21 Mark Polesky :
> I rewrote x11-color.scm so that now the color-list is generated
> semi-automatically. It's more organized, easier to read, and less
> than a quarter of its original size. But does my approach slow
> things down at all? Measurably? I figure the current version is
> probabl
On Thu, Jul 23, 2009 at 12:15 AM, Neil Puttock wrote:
> 2009/7/21 Mark Polesky :
>> I rewrote x11-color.scm so that now the color-list is generated
>> semi-automatically. It's more organized, easier to read, and less
>> than a quarter of its original size. But does my approach slow
>> things down a
On Wed, Jul 22, 2009 at 10:29:37AM +0200, John Mandereau wrote:
> Le mardi 21 juillet 2009 à 23:57 -0700, Graham Percival a écrit :
> > I still think the texinfo files should be in master, but perhaps
> > not the generated images, and not some really web-specific stuff
> > like the htaccess.
>
> I
Han-Wen Nienhuys wrote:
> Neil Puttock wrote:
> > Very nice. :)
> >
> > A good (but tedious) test of whether it's impacting on compile
> > times would be to compare doc builds with and without the
> > changes, since there are so many LilyPond invocations for the
> > snippets.
> >
>
> It sure looks
> Would it be technically feasible/possible to establish a system of
> "anchors" instead?
This would be indeed a great feature!
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
36 matches
Mail list logo
