Cool.
FYI I've had LilyPond for a week and I've gotten more done already than
months of fiddleing with Finale and about ten other GUI based programs.
LilyPond is a lifesaver in terms of reuseability and template
implementation, great job. The real power lies in the ability to template
your song
Read Section "8.2.8 Different editions from one source".
/Mats
Rick Hansen (aka RickH) wrote:
I'm a guitarist but have a suggestion for a new command LilyPond.
When entering a standatrd notes staff... on guitar music it is customary to
place roman numerals of the current fretting position
I'm a guitarist but have a suggestion for a new command LilyPond.
When entering a standatrd notes staff... on guitar music it is customary to
place roman numerals of the current fretting position just below the staff
(section 7.5.5 of v2.8.0 manual).
When entering a tab staff... it is also nec
It's up to you as a user to do this. Just write a .ly file with all
your favourite style changes and use
\include "mystyle.ly"
in your scores.
The thing is that it is possible to separate layout from content
in LilyPond, but it is not enforced and maybe not even encouraged enough.
/Mats
Quot
On Tuesday 04 April 2006 21.37, Han-Wen Nienhuys wrote:
> Erik Sandberg wrote:
> > On Tuesday 04 April 2006 20.46, Han-Wen Nienhuys wrote:
> >> Han-Wen Nienhuys wrote:
> >>> I'd start with 4. because they're independent from the rest, and we can
> >>> readily test the rest of those.
> >
> > The rea
David Feuer wrote:
On 4/4/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
David Feuer wrote:
music-drawing-routines.ps to indicate level 2. I really don't have
the time to set myself up to compile the LilyPond sources. Could you
setting yourself is actually very easy nowadays, at least if yo
David Feuer wrote:
On 4/4/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
David Feuer wrote:
music-drawing-routines.ps to indicate level 2. I really don't have
the time to set myself up to compile the LilyPond sources. Could you
setting yourself is actually very easy nowadays, at least if yo
David Feuer wrote:
Does anyone actually set /testing to test round boxes anymore, or is
that a historical artifact? I've already fixed it (in a recent patch)
artifact, please junk.
so it doesn't waste time, but it's still wasting (a bit of) space and
making the code less pretty.
--
Han-
Erik Sandberg wrote:
On Tuesday 04 April 2006 20.46, Han-Wen Nienhuys wrote:
Han-Wen Nienhuys wrote:
I'd start with 4. because they're independent from the rest, and we can
readily test the rest of those.
The reason for my ordering, is that 3 can be used to verify that 4 works.
BTW, (1-3) ar
On 4/4/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
> David Feuer wrote:
> > music-drawing-routines.ps to indicate level 2. I really don't have
> > the time to set myself up to compile the LilyPond sources. Could you
>
> setting yourself is actually very easy nowadays, at least if you're
> run
David Feuer wrote:
music-drawing-routines.ps to indicate level 2. I really don't have
the time to set myself up to compile the LilyPond sources. Could you
setting yourself is actually very easy nowadays, at least if you're
running linux or macos X. Just go to
http://lilypond.org/~hanwen
On Tuesday 04 April 2006 20.46, Han-Wen Nienhuys wrote:
> Han-Wen Nienhuys wrote:
> > I'd start with 4. because they're independent from the rest, and we can
> > readily test the rest of those.
The reason for my ordering, is that 3 can be used to verify that 4 works.
BTW, (1-3) are completely ind
Does anyone actually set /testing to test round boxes anymore, or is
that a historical artifact? I've already fixed it (in a recent patch)
so it doesn't waste time, but it's still wasting (a bit of) space and
making the code less pretty.
David Feuer
_
On 4/4/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
> we don't do level 1 anyway. I think that glyphshow is L2.
You're right! So I can remove the level 1 emulation code I put in for
selectfont. And we should change the PostScript comment at the top of
music-drawing-routines.ps to indicate l
David Feuer wrote:
On 4/4/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
The reason for having C++ is historical.
I'm not certain that using Scheme for everything will lower hackability
of the code, eg. I'm still not as fluent in Scheme as in C++ --with all
its shortcomings. Also, having opa
David Feuer wrote:
Use the postscript "arct" command. Drawing a filled polygon becomes
x0 x1 add 2 div y0 y1 add 2 div moveto
x1 y1 x2 y2 r arct
x2 y2 x3 y3 r arct
x3 y3 x4 y4 r arct
...
x(n-1) y(n-1) x0 y0 r arct
x0 y0 x1 y1 r arct
closepath
fill
where n is the number of points and r is the r
I don't understand your question. Properties inherit from Score
downwards. Usually, bottom context doesn't have any property set, only
inherited values.
David Feuer wrote:
Why are properties set by default in the bottom context? I think it
would make more sense to do what Postscript does wi
While I'm at it, the Scheme and Postscript polygon drawers are only
ever called with the filled parameter true, so please get rid of that
parameter.
David Feuer
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinf
Why are properties set by default in the bottom context? I think it
would make more sense to do what Postscript does with dictionaries and
set them by default in the lowest context that has those properties.
David Feuer
___
lilypond-devel mailing list
On 4/4/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
> The reason for having C++ is historical.
>
> I'm not certain that using Scheme for everything will lower hackability
> of the code, eg. I'm still not as fluent in Scheme as in C++ --with all
> its shortcomings. Also, having opaque C++ objec
Use the postscript "arct" command. Drawing a filled polygon becomes
x0 x1 add 2 div y0 y1 add 2 div moveto
x1 y1 x2 y2 r arct
x2 y2 x3 y3 r arct
x3 y3 x4 y4 r arct
...
x(n-1) y(n-1) x0 y0 r arct
x0 y0 x1 y1 r arct
closepath
fill
where n is the number of points and r is the radius of the arc.
ar
Han-Wen Nienhuys wrote:
I'd start with 4. because they're independent from the rest, and we can
readily test the rest of those.
I mean: test the results of those.
(I need to take a break :-)
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design
-
David Feuer wrote:
What's the rationale behind the division into C++ and Scheme? I don't
quite see why Lilypond uses C++ and Guile rather than using a serious
Scheme implementation (like PLT) and working to shift code from C++
over to Scheme.
The reason for having C++ is historical.
I'm not
Han-Wen Nienhuys wrote:
it would actually be fairly trivial. You can already \tag music events;
you'd only need to write an engraver that catches tagged grobs, and
sorry, I meant: tagged events.
applies any grob properties necessary.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.
Erik Sandberg wrote:
Hi,
Here's my plan on how to front-port music streams to the 2.9 branch.
1. Implement classes Dispatcher, Stream_event, Listener (move modules from my
thesis fork)
2. Add dispatchers event_source_, and possibly events_below_, to Context
class.
3. Make Context::try_music
David Feuer wrote:
On 4/4/06, Geoff Horton <[EMAIL PROTECTED]> wrote:
After upgrading to 2.8.1, I notice that the .pdf files produced are
considerable larger, on the order of about 5 to 10 times the size
formerly produced. This has a detrimental effect on my ability to
store and distribute, so
David Feuer wrote:
I'm sure someone has brought this up before, but I've been thinking a
bit about the way users tweak output in Lilypond. As it is, tweaks
are generally interspersed with actual music information. This seems
to make things difficult when someone tries to maintain a part that
ha
David Feuer wrote:
On 4/4/06, Pedro Kröger <[EMAIL PROTECTED]> wrote:
Paul Scott <[EMAIL PROTECTED]> writes:
It's simple. Scheme code will probably never run as fast as C++.
Unless, of couse, one uses a scheme compiler that can generate fast
code, like bigloo [1].
Or a Scheme system like P
On 4/4/06, Geoff Horton <[EMAIL PROTECTED]> wrote:
> > > After upgrading to 2.8.1, I notice that the .pdf files produced are
> > > considerable larger, on the order of about 5 to 10 times the size
> > > formerly produced. This has a detrimental effect on my ability to
> > > store and distribute, s
Hi,
indeed, this topic has been brought up at least in early 2003 (maybe even
earlier) and also went into Han-Wen's and Jan's XIV CIM 2003 paper (see
right column of page 4 in this paper). There _is_ already an implicit way
of writing style sheets (although somewhat limited), but let me expla
On 4/4/06, Pedro Kröger <[EMAIL PROTECTED]> wrote:
> Paul Scott <[EMAIL PROTECTED]> writes:
>
> > It's simple. Scheme code will probably never run as fast as C++.
>
> Unless, of couse, one uses a scheme compiler that can generate fast
> code, like bigloo [1].
Or a Scheme system like PLT that uses
On 4/4/06, Carl D. Sorensen <[EMAIL PROTECTED]> wrote:
> Carl Sorensen here:
>
> But this flies in the very face of Lilypond's objective. The objective
> for lilypond is to have an automatic engraver that takes the music
> information and creates a beautiful engraved score. We don't want to
> tw
Paul Scott <[EMAIL PROTECTED]> writes:
> It's simple. Scheme code will probably never run as fast as C++.
Unless, of couse, one uses a scheme compiler that can generate fast
code, like bigloo [1].
Pedro
Footnotes:
[1] http://www-sop.inria.fr/mimosa/fp/Bigloo/
__
Lilypond draws beams as polygons. The polygon code (in lookup.cc) is
hairy, and probably slow. It'd be much easier and faster to make
beams trapezoids. More generally, from reading the comments on the
polygon code, I get the feeling it might be best to get rid of it
altogether. I'm looking thro
-Original Message-
From: David Feuer [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 04, 2006 9:57 AM
To: lily-devel
Subject: Style
I'm sure someone has brought this up before, but I've been thinking a
bit about the way users tweak output in Lilypond. As it is, tweaks are
generally int
David Feuer wrote:
What's the rationale behind the division into C++ and Scheme? I don't
quite see why Lilypond uses C++ and Guile rather than using a serious
Scheme implementation (like PLT) and working to shift code from C++
over to Scheme.
It's simple. Scheme code will probably never run
What's the rationale behind the division into C++ and Scheme? I don't
quite see why Lilypond uses C++ and Guile rather than using a serious
Scheme implementation (like PLT) and working to shift code from C++
over to Scheme.
David
___
lilypond-devel ma
Hi,
On Tue, 4 Apr 2006, David Feuer wrote:
> I'm sure someone has brought this up before, but I've been thinking a
> bit about the way users tweak output in Lilypond. As it is, tweaks
> are generally interspersed with actual music information. This seems
> to make things difficult when someone
I'm sure someone has brought this up before, but I've been thinking a
bit about the way users tweak output in Lilypond. As it is, tweaks
are generally interspersed with actual music information. This seems
to make things difficult when someone tries to maintain a part that
has to be transposed a
David Feuer schreef:
Patch now has directory names.
David Feuer
looks good.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design
-- Code for Music Notation
http://www.lilypond-design.com
___
lilypond
I should note that this patch probably has bugs.
David
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Patch now has directory names.
David Feuer
newpatchdir.diff
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Hi,
Here's my plan on how to front-port music streams to the 2.9 branch.
1. Implement classes Dispatcher, Stream_event, Listener (move modules from my
thesis fork)
2. Add dispatchers event_source_, and possibly events_below_, to Context
class.
3. Make Context::try_music send stream events to th
Han-Wen Nienhuys wrote:
Could you also update Documentation/topdocs/AUTHORS.texi and THANKS in a
next patch?
come to think of it, I already did :)
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design
-- Code for Music Notation
http://www.lilypond
David Feuer wrote:
The attached patch stops LilyPond from compulsively gsave/grestoring
everything. It changes some procedures so they don't need
gsave/grestore, and it adds gsave/grestore and translate to the ones
that do. Do you think I should put the gsave/grestore back into
draw_polygon, or
David Feuer wrote:
2006-04-03 David Feuer <[EMAIL PROTECTED]>
* lilyponddefs.ps (set-ps-scale-to-lily-scale): Fixed code duplication.
* Cleaned up interfaces between PostScript and Scheme, and moved computations
from PostScript to Scheme:
* music-drawing-routines.ps
(*SF, stroke_and_fill): n
Herman Grootaers wrote:
On Tuesday 04 April 2006 10:47, Andreas Scherer wrote:
R. Mattes mh-freiburg.de> writes:
Ok, i found the "bug". It looks like this is triggered
by using guile-1.6.n instead of guile-1.8 - this also
explains why Andreas' build failed.
Confirmed. After updating OpenSUSE
David Feuer wrote:
Attached is a patch that might be more controversial than the one I
just submitted (it goes on top of that one, and is pretty small).
This one creates a Scheme macro for using str4 in format calls. I
don't know if you'll think it's great or just plain ugly. I'm not
sure wha
On Tuesday 04 April 2006 10:47, Andreas Scherer wrote:
> R. Mattes mh-freiburg.de> writes:
> > Ok, i found the "bug". It looks like this is triggered
> > by using guile-1.6.n instead of guile-1.8 - this also
> > explains why Andreas' build failed.
>
> Confirmed. After updating OpenSUSE 10.0 with g
R. Mattes mh-freiburg.de> writes:
> Ok, i found the "bug". It looks like this is triggered
> by using guile-1.6.n instead of guile-1.8 - this also
> explains why Andreas' build failed.
Confirmed. After updating OpenSUSE 10.0 with guile-1.8.0, all is well again.
"make all web" runs to completion w
HiOn 4/4/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
I guess not, although I don't personally see the use (my sourcedirectory is a complete mess anyway because I dump all my debugging .lyfiles there)Well, I guess that there are other developers that might need this. I see no problem with the na
Hi,
I haven't had the time to catch up with all the bugs that have been reported
over the past few weeks. This is largely because of Real Life issues (i.e., I
haven't had time). Furthermore, I will start a new job next week, which will
further restrict my lilypond time.
I have concluded that t
52 matches
Mail list logo
