ts through a
script.
> I have an idea about this, but i'll have to think about it more before
> posting.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lis
ings are using scalable fonts,
the correct approach is to figure out how to add hinting to the fonts
so the stems are not brushed on 600 dpi and coarser printers.
(I hope you're not suggesting to remove the brushing.)
>
> best,
> Janek
--
Han-Wen Nienhuys - han...@xs4all.nl - http://
ering: what started it all off?
>
> Here's a link to an arrangement I made that I intend to convert to LilyPond:
> http://www.stewartfrench.com/brahms/
>
> With admiration,
> Stewart French
>
>
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
e 1.8-2.0
syntax change. It is a pain in the ass, because when copying music,
you have to remember to put some adornments (ie. the ')' ) before the
note, while most go after the note. With everything postfix, things
are both easier to parse in LilyPond, and easier to type for humans.
--
Han-
r the GPL in order to include LilyPond.
HTH,
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanw
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
//www.edition-kainhofer.com>
>
> __**_
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/**listinfo/lilypond-devel<https://lists.gnu.org/mailman/listinfo/lilypond-devel>
>
--
Han-Wen Nien
They have to be spanners - if the mm rest is broken across a linebreak, the
text should be too.
On Thu, Apr 4, 2013 at 7:01 PM, Janek Warchoł wrote:
> Hi Han-Wen,
>
> On Thu, Apr 4, 2013 at 10:48 AM, Han-Wen Nienhuys
> wrote:
> > I think this is because these are texts th
opriate X-parent and use that for alignment), but
> i don't know how to set that parent - the obvious way failed... Check
> out attached patch, and the testfile. Ideas?
>
> cheers,
> Janek
>
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
as a new framework (FP6) for
research programs, which was more focused on large businesses, which
made our project proposal even more problematic. I don't know what FP7
looks lke, but you should definitely talk to people involved with EU
programs now to know what you're getting into.
expected that the second number would be -1.251178.
IIRC, the refp should be an ancestor of the grob you're asking for.
This means only one of
obj->relative_coord(refp, X)
refp->relative_coord(obj, X)
is valid.
--
Han-Wen Nienhuys - han..
ecision and doing the thankless job
of bringing the code base into conformance. It's also a topic that
easily generates a lot of discussion (bikeshedding) where each opinion
is equally good, objectively speaking.
(Since code formatting is such a distraction, Google
, we are talking
> about post-1960s Pascal coding, and he tried his best to still present
> things in a structured way, in well-documented meaningful chunks.
>
> Nowadays we have much more modular programming languages, and we make a
> mess of it. I consider doing good work with bad tool
se significant extracts of the resulting PDF.
While tex.web is a beautiful example of literate programming, it was
a. created by one the worlds' foremost computer scientists.
b. created for a program whose behavior and code was to be set in stone.
I think that looking at tex.web will no
___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
-- Forwarded message --
From: Kristina Vuckovic
Date: Fri, Dec 28, 2012 at 11:29 AM
Subject: LilyPondXs
To: han...@xs4all.nl
J fo
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
Huh? Isn't dist generated by asking Git nowadays?
On Fri, Dec 21, 2012 at 7:57 AM, wrote:
> I suspect that the GNUMakefile.in will need .OFL to be added to the
> EXTRA_DIST.
>
> https://codereview.appspot.com/6970046/
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.
change is here https://codereview.appspot.com/6970046/
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
from time to time before from others, and
the OFL is a way to answer all these questions in one fell swoop.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
t; those people slightly involved in lilypond. However, I'm not
> going to be the person doing such organization any more.
>
> We've had a number of people recently warning about less energy
> for LilyPond, so I know that this email isn't perfectly timed.
> But hey, that's life. The next few months
On Sun, Sep 9, 2012 at 1:22 PM, Joseph Rushton Wakeling
wrote:
> On 08/09/12 16:10, Han-Wen Nienhuys wrote:
>>
>> I have in the past talked with people from Henle; also, Schirmer has a
>> style guide that you can order as a book.
>
>
> How far in the past are we tal
On Sat, Sep 29, 2012 at 11:35 AM, m...@mikesolomon.org
wrote:
>
> On 29 sept. 2012, at 10:59, Han-Wen Nienhuys wrote:
>
>> On Wed, Sep 26, 2012 at 10:40 PM, David Kastrup wrote:
>>> Han-Wen Nienhuys writes:
>>>
>>>> In order to do cache invalidation
On Wed, Sep 26, 2012 at 10:40 PM, David Kastrup wrote:
> Han-Wen Nienhuys writes:
>
>> In order to do cache invalidation, you will have to construct the
>> reverse graph. If A.x depends on B.y, now A points to B. For proper
>> cache invalidation, if B.y changes, then A
ges, then A.x becomes invalid. This
means that A has to store a back-reference to B. Hence all pointers
have to be stored both ways (including inverting 1-N relations into
N-1 relations), and the both-way links have to be rewritten correctly
during line breaking.
--
Han-Wen Nienhuys - han...@xs4all.nl
lt; \vOne \vTwo >>
}
without this affecting the typesetting.
I would advise against overloading the meaning of existing constructs,
as it will have compatiblility implications.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
and takes an hour of extra time.
I would argue that this is an indication that the \tempo syntax is a
mistake. If making backward incompatible changes is allowed, I would
suggest to reconsider and scrap the onerous parts of its syntax.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4al
On Wed, Sep 12, 2012 at 12:04 PM, David Kastrup wrote:
> Han-Wen Nienhuys writes:
>
>> On Wed, Sep 12, 2012 at 5:38 AM, David Kastrup wrote:
>>>
>>> Hi,
>>>
>>> if we write xxx in LilyPond, this is considered to be a string. I want
>>&
ither a string (keySignature) or list of string. Are
music function equipped to deal with this type of polymorphism.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
I'd strongly recommend implementing this and copying a few pages of
music before making any decisions. The everything postfix decision
was made after I had to copy music, and realized how jarring it was to
have to remember what goes where when copying music; I fear that your
proposal will require remembering more details.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
so far.
Can you clarify? Boehm GC should also be inspecting the stack for what
might be pointers to memory that cannot be reclaimed. See also
http://www.gnu.org/software/guile/manual/html_node/Conservative-GC.html
if your point is that some blocks will not be GC'd, then that is
nothing new; p
On Sat, Sep 8, 2012 at 12:00 PM, David Kastrup wrote:
> Han-Wen Nienhuys writes:
>
>> On Fri, Sep 7, 2012 at 4:42 AM, David Kastrup wrote:
>>>> There's one thing worth clarifying: when i say "syntax changes", i
>>>> mean "changes in how
le, a business model which
makes ever less sense in the digital age.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
with either lexer.ll or parser.yy. As long as you don't that, I will
not object fiercely to what syntax proposal anyone comes up with.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On Tue, Sep 4, 2012 at 6:25 PM, Han-Wen Nienhuys wrote:
>>>> Isn't this an argument for delimiting the argument list?
>>>
>>> It is. The disadvantage is that it breaks all existing files.
>>
>> I think i remember one of the developers saying "
ind anything about these in beam-quanting,
> can you help?
>
See Beam_scoring_problem::solve(); the first number is the index of
the chosen solution, the second the number of candidates.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
_
ips with it initially.
>
> So I'd be happy to let David continue his work straightening out the
> parser, which is good, and improving the functionally, even better.
> But if we are to have a discussion about syntax let's first list the problems
> we need to solve, and rea
On Tue, Sep 4, 2012 at 3:40 PM, Janek Warchoł wrote:
> On Tue, Sep 4, 2012 at 5:54 PM, Han-Wen Nienhuys wrote:
>>
>>> Isn't this an argument for delimiting the argument list?
>>
>> It is. The disadvantage is that it breaks all existing files.
>
> I thin
files.
> If you don't expect
> anyone to guess where it begins and ends correctly (and I didn't), doesn't
> that mean we should have a more explicit syntax?
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
nce \skip4 now
would be a identifier dereference.
My request for having parser patches is also grounded in this. Basic
problems with most syntax changes become readily apparent if you try
to change the parser grammar; since they often lead to ambiguities
which Bison cannot resolve.
Such consideratio
th the current syntax, this is certainly true. But if a music function's
> arguments were delimited syntactically somehow then we could parse without
> interpreting any music functions, right?
Correct.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
eading
>> it is parsing, evaluating it interpretation.
>
> Ouch. Sound like something we seriously don't want at all.
Right - this means that we seriously don't want to be a music
interchange/storage format.
--
Han-Wen Nienhuys - ha
On Mon, Sep 3, 2012 at 11:46 AM, David Kastrup wrote:
>
> I actually remembered one thing that remains worth doing: integrating
> \chordmode into \notemode.
This sounds like a nice project. I am still worried by the backward
compat breakage, though. Is it worth it?
--
Han-Wen Nienh
On Mon, Sep 3, 2012 at 9:03 AM, David Kastrup wrote:
> Graham Percival writes:
>
>> On Mon, Sep 03, 2012 at 02:20:43AM -0300, Han-Wen Nienhuys wrote:
>>> To me, a Grand Input Syntax "fixing" of LilyPond, would amount to
>>> creating a syntax that stric
rall scheme, and also make some things easier to get done with. With
> regard to _designing_ the language of LilyPond, I think we are better
> off discussing and relating our goals, and seeing where this takes
> development.
+1
--
Han-Wen Nienhuys - han...@xs4al
On Mon, Sep 3, 2012 at 9:00 AM, Graham Percival
wrote:
> On Mon, Sep 03, 2012 at 01:24:22AM -0300, Han-Wen Nienhuys wrote:
>> On Sat, Sep 1, 2012 at 4:39 PM, Graham Percival
>> wrote:
>>
>> > The meta-target is "after spending 5 years very publicly
>
al
relationship. I have been dealing with syntax changes and
"improvements" for many years; and it is tiring. Why can't people see
the world from our perspective for a change?
> I mean, what possible downsides are there to this? It will be
I have only so much time. Don't waste i
I would like to see
all proposals in the form of a parser patch that does not introduce
extra shift/reduce or reduce/reduce conflicts, and maintains general
backward compatibility. If a proposer manages to get that far, I
promise I will take a serious look at it.
--
Han-Wen Nienhuys - han.
terpretation.
This implies not only rethinking a lot of syntax, but also it means
letting go of some of the flexibility and conciseness of the current
format.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
end up
with virtually no changes. I guess that such is life.
> Of course many of our ideas will not be good. That's fine!
> That's how creative thinking works!
No; syntax discussions without understanding how the lilypond parser
works is just blowing around hot air and discussi
ly helpful.
>
> I've compiled with -DDEBUG_BEAM_SCORING=1
this is the default already; see include/main.hh
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On Sat, Sep 1, 2012 at 12:04 PM, David Kastrup wrote:
> Han-Wen Nienhuys writes:
>
>> On Sat, Sep 1, 2012 at 8:27 AM, David Kastrup wrote:
>>
>>> It is reasonably easy to state "this will have to go". However, I have
>>> not so far att
ts in identifiers, it has
irked me for years that we could not get it to work. I vaguely recall
you implemented this in 2.16 already, but I guess I am mistaken?
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
uld make it possible
> to create "more of the same".
Be careful with the wheels. It may be impossible to remove them in the future.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
and have the user be explicit about what he is doing.
The discussion about syntax changes is not going to work unless we
know in what direction we want to go.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On Sat, Sep 1, 2012 at 8:11 AM, Graham Percival
wrote:
> On Fri, Aug 31, 2012 at 11:11:28PM -0300, Han-Wen Nienhuys wrote:
>> I have become convinced that optional, unnamed arguments are not a
>> happy design decision, in any language. In Lily it's particularly
>> p
On Sat, Sep 1, 2012 at 11:42 AM, Han-Wen Nienhuys wrote:
>>> \tempo \markup{ Presto } 4. = 172 ~ 188
>>> c1 c
>>> }
>>
>> While this might be a mess for the parser to sort out it is perfectly
>> understandable for a musician trying to write his/
On Sat, Sep 1, 2012 at 8:27 AM, David Kastrup wrote:
> Graham Percival writes:
>
>> On Fri, Aug 31, 2012 at 11:11:28PM -0300, Han-Wen Nienhuys wrote:
>>> I have become convinced that optional, unnamed arguments are not a
>>> happy design decision, in any langu
gt; is replaced the replacement must be as acceptable to a musician,
> otherwise we're going backwards.
I think "a musician" is red herring word. There are many people that
think that Lily is too complex for "musicians" already, and many
others (including me) that think that
s only possible when there is no lookahead token yet.
>
> This is stalling things like
> http://code.google.com/p/lilypond/issues/detail?id=2067> and leads
> to behavior surprising to users.
Why should this be in a music function at all? If the user knows
enough scheme to understand tha
re intended to be used without side-effects, so there is a little
difference between a function and a built-in input language construct,
such as \times.
> I think in Perl you can have functions
> look like dead statements, but that's probably just making the argument
> better.
--
s are easy to spot. I think in Perl you can have functions
> look like dead statements, but that's probably just making the argument
> better.
I find it interesting that you are giving Perl while we are
discussing readability.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
ic
> functions such as \relative, so Janek and I are re-thinking the
> proposal. Jan threw out the idea that music functions could be
> denoted with a different symbol, i.e.
> @relative {
> a4 @parenthesis b c d
> a4-\staccato b c d
> }
> but that was just an of
is will mostly be about tweaking scoring functions, and
making sure existing situations stay the same.
>
> best,
> Janek
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
ty of ly, it would certainly be a good way of interfacing in a
While sxml is certainly nice, I wouldn't overstate its usefulness. The
big problem with musicxml is that it has a data model that is
completely different from anything inside lilypond, something that
sxml does not help a lot wit
lyPond just does
> not enforce it.
>> Thoughts? opinions? alternatives that I haven't considered?
>> These discussions are going to produce a *lot* of emails.
>
> And if they come to conclusions, they are going to produce effects on
> everybody. Including people using &quo
t participate in it?
I personally am not inclined to subscribe to yet another list. Also,
finding the discussion later on will be easier if it happens on
lilypond-devel.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
th this approach.
>
> Best,
> John
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>
--
Han-Wen Nienh
__
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
r so that the
> slur was less bound to the edges.
AFAICS, this is designed so the ends of the slur stay close to base_attachment_
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@g
g! LilyPond 2.16 was brought to you by.
>
> Main development team:
> Bertrand Bordage, Trevor Daniels, Phil Holmes, Ian Hulin, Reinhold
> Kainhofer, David Kastrup, Jonathan Kulp, Werner Lemberg, John
> Mandereau, Patrick McCarty, Joe Neeman, Han-Wen Nienhuys, Jan
> Nieuwenhuizen,
font:
Author: Aleksandr Andreev
Author: Bertrand Bordage
Author: Carl Sorensen
Author: Carsten Steger (*)
Author: Glen Prideaux
Author: Han-Wen Nienhuys
Author: Janek Warchol
Author: Jan Nieuwenhuizen
Author: Jurgen Reuter
Author: Marc Hohl (*)
Author: Mats Bengtsson
Author: Maximilian Al
{http://enc2ly.sourceforge.net/en/,Enc2ly} is a GNU/Linux program
> +which converts an @uref{http://www.gvox.com/,Encore} music score into
> +a LilyPond one.
> +
> @end itemize
>
> @subsubheading Algorithmic code generators
>
>
>
Janek Warchoł wrote:
> Hey all,
>
> attached example might be a better-looking suggestion of
> non-christmas-tree flags ;)
> I'd be happy to Metafont them as an optional font variant - if someone
> writes the architecture.
>
> cheers,
> Janek
--
Han-Wen Nienhuys - ha
curate. **Does anyone have the same feeling? And please take look
> at the atachment - this is how perfect flags should look like to me.
In your example, the top hook looks larger than the other ones,
especially in 32, 64 and 128, because it has nothing above it.
--
Han-Wen Nienhuys - han...
is-page-break?)
one entry for each line-break. You should be able to plug this in to
the code rather straightforwardly. If you only have to do it once per
line, the spacing computation is actually pretty cheap, so you get
most of the benefit with just this information.
You can use Sch
;t think it would be very easy to do this with GNU Make
I believe the android build works like this, so it should be doable.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On Sat, Aug 4, 2012 at 3:41 PM, Han-Wen Nienhuys wrote:
> Hi Felipe,
>
> I got go-enc2ly such that it prints useful output for simple scores (try eg.
> http://www.samba-choro.com.br/partituras/porartista/vermusica?mid=8544&pos=156
> ); there are some installation instruct
;t let us distinguish
between
\times 2/3 { c4 c4 c4 c4 c4 c4 }
and
\times 2/3 { c4 c4 c4 } \times 2/3 { c4 c4 c4 }
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://list
; you'd have to eliminate all
timestamps (set them to the ts from the latest git commit for
example).
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
should be the guiding principles for any kind of change
we contemplate.
I also think that there are very few changes that could meet these
standard because:
* what people can do is very often limited by the typesetting
infratstructure rather than syntax
* the lexer/parser is complex, but it is s
ere
> is actually quite a bit of actually non-working code due to trying to
> manually simulate rational arithmetic and getting it wrong.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
li
s a few times. I'll let him sort it out with Colin
was Phil successful?
> Hall as to who does it next, or whether he wants to give you admin
> on the issue tracker so that you can do it.
>
> - Graham
>
> ___
> lilypond-devel m
ely consistent with GNU's position.
neither scorio nor tunefl are considered non-free programs, so they
should be OK. FSF's beef is with restrictive licensing, since
licensing means you cannot freely copy the software ("share with your
neighbors").
--
Han-Wen Nienhuys - han...@xs
on of things in all staves . Also,
grobs that align on parents should usually have something more
specific as X-parent (eg. a notehead).
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
andling (mainly
Jan complaining of mine). Those fights always were caused by
discussing things in a hurry over e-mail, and were always resolved
when we called to discuss things over the telephone.
I warmly recommend getting together, hacking, thinking and drinking
some beer (or whatever your preferr
t-interface.cc
> M scm/define-grob-properties.scm
> M scm/define-grobs.scm
>
>
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
_
leases with. AFAICS, they are almost all eminently usable.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
tion to try using it
> without doing a complete GUB build.
it would be best if "make dist" were rewritten to take git's idea of
the tree, and then add any necessary generated files (eg. configure,
README) to that.
--
Han-Wen Nienhuys - han...@xs
auto beaming is weird, because it has to emit a
Beam after the real end point has already passed. However, wouldnt it
be easier to simply use manual beams in the example? Putting a
footnote on something automatically generated sounds like a bad
practice, since it stops making sense when you alter
or streamlining stuff before one caches it.
Run a profile. These examples may not be the pinnacle of elegance, but
unless you can measure it makes any difference, we shouldn't bother
optimizing it.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
__
dealing with regressions, and you are
>> not exactly going to end up ahead, anyway.
>>
>
> This is not untrue... :)
> Bottom line - CONGRATS TO EVERYONE. This is the most prestigious open-source
> music software competition in the world. Get excited!
Congrats to everyone, including m
[correct Jan's address]
On Mon, Apr 30, 2012 at 5:02 PM, Han-Wen Nienhuys wrote:
> On Mon, Apr 30, 2012 at 3:21 PM, Janek Warchoł
> wrote:
>>>>> I'm trying to use the nice Feta braces in an OpenType math font I'm
>>>>> working on[1] th
Jan's and my work, with some tweaks by Werner.
I don't mind relicensing the font under a more permissible license.
Werner, do you know of a suitable license for open source fonts?
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On Fri, Apr 27, 2012 at 10:15 AM, Han-Wen Nienhuys wrote:
> Who is GNU_LilyPond anyway? I thought it was, but I might be mistaken.
I mean: I thought it was Jan.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilyp
Who is GNU_LilyPond anyway? I thought it was, but I might be mistaken.
On Fri, Apr 27, 2012 at 9:39 AM, Graham Percival
wrote:
> On Fri, Apr 27, 2012 at 09:19:55AM -0300, Han-Wen Nienhuys wrote:
>> Is it possilble to display the contents of the twitter #lilypond
>> hashtag a
nd. Click <a target="_blank"
> href="http://www.ensemble101.fr">here</a>; to learn more!
>
>
>
>
>
> http://codereview.appspot.com/6068045/
>
> ___
> lilypond-devel mailing list
> lilypond-devel
future.
>
> Cheers,
> MS
>
> P.S. Sorry for the last-minuteness of this e-mail: I had sent it from
> m...@mikesolomon.org and it didn't go through. I'll have to change e-mail
> addresses on the list...
>
> ___________
>
scm_gc_mark (solo_two_event_->self_scm ());
> }
>
> All the rest is too smart for its own good.
FYI, my experience is that writing this type of code involves cut &
paste, and it is easy to make errors like
if (some_new_event_)
mark(the_event_i_copied_it_from_)
I agree that 4
xpect that it should add
current[d][RIGHT] - previous[d][LEFT]
perhaps this will set rods too large if you have lots of ledgered
chords with seconds in them, in a tight spacing configuration.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
t into the project, so it
is good to be conservative with applying them. That said, I think a
macro for this pattern is justified given its frequency of appearance.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel
so:
http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/faqs#goals
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
601 - 700 of 4508 matches
Mail list logo
