On 2012/09/04 08:14:46, mike7 wrote:
On 4 sept. 2012, at 07:36, mailto:k-ohara5...@oco.net wrote:
I can't get it to work for the script at the start of the tie.
\relative c''' { r2. c4~- | c- r2. }
The reason is because ties are announced at a timestep (maybe
several) after their
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
about ten years (I estimate) prior to the
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
On Tue, Sep 4, 2012 at 11:22 PM, Trevor Daniels t.dani...@treda.co.uk 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
Trevor Daniels t.daniels at 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
On Wed, 05 Sep 2012 00:50:27 -0700, d...@gnu.org 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 :
Janek Warchoł janek.lilypond at 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
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
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
Keith OHara k-ohara5...@oco.net 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
(sorry, Keith, forgot to cc the list)
On Wed, Sep 5, 2012 at 10:59 AM, Keith OHara k-ohara5...@oco.net 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
On Wed, Sep 5, 2012 at 11:51 AM, d...@gnu.org 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
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 Tue, Sep 4, 2012 at 6:22 PM, Trevor Daniels t.dani...@treda.co.uk 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
On Mon, Sep 3, 2012 at 10:46 AM, Janek Warchoł janek.lilyp...@gmail.com 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
On Tue, Sep 4, 2012 at 6:25 PM, Han-Wen Nienhuys hanw...@gmail.com 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
Janek Warchoł janek.lilyp...@gmail.com writes:
On Tue, Sep 4, 2012 at 5:54 PM, Han-Wen Nienhuys hanw...@gmail.com 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
Bernard Hurley bern...@marcade.biz 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
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 disadvantage is
2012/9/4 Trevor Daniels t.dani...@treda.co.uk:
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
Werner LEMBERG w...@gnu.org 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 quite nice.
Francisco Vila paconet@gmail.com writes:
2012/9/4 Trevor Daniels t.dani...@treda.co.uk:
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
On Wed, 05 Sep 2012 02:54:38 -0700, Trevor Daniels t.dani...@treda.co.uk
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
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
Keith OHara wrote Wednesday, September 05, 2012 10:44 PM
On Wed, 05 Sep 2012 02:54:38 -0700, Trevor Daniels t.dani...@treda.co.uk
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
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
Reinhold Kainhofer reinh...@fam.tuwien.ac.at 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
On Wed, 05 Sep 2012 15:47:18 -0700, Trevor Daniels t.dani...@treda.co.uk
wrote:
On Wed, 05 Sep 2012 02:54:38 -0700, Trevor Daniels t.dani...@treda.co.uk
wrote:
There are many places in LilyPond now where delimiters are necessary
to resolve certain situations but are not generally mandatory.
Francisco Vila paconet.org at 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.
David Kastrup dak at 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
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
31 matches
Mail list logo
