I like it, but we need to figure out what went wrong with
'accidental-tie.ly'. There was some trickery involving holding space
open for the accidental that might be needed on the second note of a
tied pair, iff the tie is broken across lines.
Ted Ross' textbook puts the upper flat about 0.5 staf
Works in realistic cases, and uses less code.
What's not to love?
http://codereview.appspot.com/6500058/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
David Kastrup gnu.org> writes:
> I proposed already at one point of time to require writing 4.0 rather
> than 4. for the floating point number. This will not cure a lot of use
> cases, and we still have the ambiguity between 4 the duration and 4 the
> integer, and -4 the fingering and -4 the int
Francisco Vila gmail.com> writes:
> For newcomers, the whole paradigm is a challenge. However, once they
> have the basics, musicians can learn the rules.
>
> \offtopic {
[...]
> } % off-topic.
I found your \offtopic section, Francisco, to be quite relevant to the topic in
fact.
On Wed, 05 Sep 2012 15:47:18 -0700, Trevor Daniels
wrote:
On Wed, 05 Sep 2012 02:54:38 -0700, Trevor Daniels
wrote:
There are many places in LilyPond now where delimiters are necessary
to resolve certain situations but are not generally mandatory.
Most of the examples require { .. } iff
Reinhold Kainhofer writes:
> What makes lilypond unfeasiable as a storage format is that its
> internals change so often. In particular, we currently have the
> viewpoint that changes to \overrides are internals, so we don't have
> to care about compatibility. In other words: We care only about
>
On 2012-09-03 22:43, Werner LEMBERG wrote:
From a user's point of view who has to write a lot of piano music,
`q' is *really* valuable.
In a score editor. Like Emacs' LilyPond-mode. Or Frescobaldi.
Nobody says that you should not be able to make use of shortcuts,
but that does not mean tha
Keith OHara wrote Wednesday, September 05, 2012 10:44 PM
> On Wed, 05 Sep 2012 02:54:38 -0700, Trevor Daniels
> wrote:
>>
>> There are many places in LilyPond now where delimiters are necessary
>> to resolve certain situations but are not generally mandatory.
>
> My brain is maybe not engagin
See
http://code.google.com/p/lilypond/issues/detail?id=2811
Compare mine to its.
You'll see programming errors - which seem to appear on all the other
recent patch tests.
James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.
On Wed, 05 Sep 2012 02:54:38 -0700, Trevor Daniels
wrote:
Keith OHara wrote Wednesday, September 05, 2012 9:59 AM
The broad question is: Require delimiters to clarify context (for users,
LilyPond, and software importing LilyPond) -- more or less?
There are many places in LilyPond now where
Francisco Vila writes:
> 2012/9/4 Trevor Daniels :
>> So what problems do the users have, exactly? We should address this
>> question first. Janek apparently has his list, which would be a good start.
>> But we should not invent problems where they don't exist. I've probably
>> read every emai
Werner LEMBERG writes:
>> Here is another "cure" for that request: if we can get used to
>> writing
>>
>> "violin1" = { ... }
>>
>> for defining a name with numbers in it, it would be an obvious
>> syntax extension to allow its invocation as
>>
>> \"violin1"
>
> Actually, I think this is quit
2012/9/4 Trevor Daniels :
> So what problems do the users have, exactly? We should address this
> question first. Janek apparently has his list, which would be a good start.
> But we should not invent problems where they don't exist. I've probably
> read every email on the user list for the last
> Here is another "cure" for that request: if we can get used to
> writing
>
> "violin1" = { ... }
>
> for defining a name with numbers in it, it would be an obvious
> syntax extension to allow its invocation as
>
> \"violin1"
Actually, I think this is quite nice.
> A somewhat non-obvious di
Bernard Hurley writes:
> On Mon, Sep 03, 2012 at 08:07:07PM +, d...@gnu.org wrote:
>>
>> flex documentation is pretty clear about backing up being very
>> expensive. I don't remember whether it was only expensive when it
>> happens, or whether the expense was more or less a fixed cost. Howe
Janek Warchoł writes:
> 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 think i remember one of the developers saying "we should also care
> for futur
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 "we should also care
>> for future users, and that's [h
On Mon, Sep 3, 2012 at 10:46 AM, Janek Warchoł wrote:
> Yep, i got it working, too. I was just looking for an explanation of
> symbols used.
>
> From what i see in beam-quanting.cc,
> L means penalty for too short/too long stems,
> H is a penalty for horizontal beams not covering staff lines,
>
On Tue, Sep 4, 2012 at 6:22 PM, Trevor Daniels wrote:
>> If I missed your point, can you state it more explicitly?
>
> I can see now my point was not stated clearly. It was:
>
> At this stage in the discussions it is important to be clear about what
> problems we are trying to solve, "In this di
> I'd say we could have a movable do for this purpose:
> \movableDo { \key d \major do re mi fa sol la si do } == \key d
> \major d e fis g a b cis d
we have it, called transpose. and we really need all features of
transpose to tell the octave correctly.
p
On Wed, Sep 5, 2012 at 11:51 AM, wrote:
> If it had been up to me, "my" Schemy-dashes and underscores would have
> gone where the sun don't shine. But while trying to create some
> more-or-less consistent syntax according to more-or-less simple rules, I
> try not to break all too many existing u
(sorry, Keith, forgot to cc the list)
On Wed, Sep 5, 2012 at 10:59 AM, Keith OHara wrote:
> The broad question is: Require delimiters to clarify context (for users,
> LilyPond, and software importing LilyPond) -- more or less?
On Wed, Sep 5, 2012 at 11:54 AM, Trevor Daniels wrote:
> There are m
Keith OHara writes:
> The readable \tempo "Adagio" 4. = 30~40 lacks the delimiters that most
> computer-entry formats require, which made it unusable in a \midi
> block for many years -- because LilyPond accepts decimal-point numbers
> in the midi block, for probably another good reason. Without
Keith OHara wrote Wednesday, September 05, 2012 9:59 AM
> I generally agree. But I also have sympathy for the desire to first clarify
> some broader questions -- such as, in which /direction/ to straighten out
> the
> parser when user problems require changes to the parser.
>
> The broad qu
On 2012/09/05 09:26:12, Keith wrote:
Agreed,
but I'll still pout a couple more times that you get your
Schemy-dashes and
underscores but I still have to refer to the motif from measure
tousend_sechshundert_siebzig
_I_ get my Schemy-dashes? I was _not_, I repeat, _not_ the person who
invente
Janek Warchoł gmail.com> writes:
> I think that for the next several weeks we should focus on gathering
> information about the /problems/ people have. Not the ideas for
> solutions. Problems.
>
> For example,
> "in { a \parenthesize b \mf c d } it's confusing what gets
> parenthesized and w
On Wed, 05 Sep 2012 00:50:27 -0700, wrote:
On 2012/09/05 06:59:16, Keith wrote:
It costs a lot of programmer time to make the extra rules to save that
0.2%,
Not really.
But, but... flex documentation is pretty clear about [getting rid of] backing
up being very expensive :
"Getting rid of
Trevor Daniels treda.co.uk> writes:
> So what problems do the users have, exactly? We should address this
> question first. Janek apparently has his list, which would be a good start.
> But we should not invent problems where they don't exist. I've probably
> read every email on the user lis
On Tue, Sep 4, 2012 at 11:22 PM, Trevor Daniels wrote:
> So what problems do the users have, exactly? We should address this
> question first.
> [...]
> But if we are to have a discussion about syntax let's first list the problems
> we need to solve, and reach agreement on which ones need to be t
On 2012/09/05 06:59:16, Keith wrote:
While we are thinking about this, I suggest we remove (later) the rule
forbidding backing-up states in the scanner. It made only a 0.2% in
the
worst-case scenario I could think of.
The rule had been violated, giving us the slightly slower scanner, for
a
30 matches
Mail list logo
