nable.
Anybody willing and able to implement?
- Bruce
-Original Message-
From: Alexander Brock [mailto:[EMAIL PROTECTED]
Sent: Monday, July 17, 2006 3:42 PM
To: Fairchild
Cc: lilypond-user@gnu.org
Subject: Re: Evolutionary User Strategery
Hello,
>
Hello,
However, modifying 'finished' scores to be acceptable by the
latest version is not reasonable. Upgrade modifications require
significant effort. The convert-ly program helps, but misses a lot.
One solution could be to write a wrapper which reads the \version and
decides which insta
Please always CC to the list.
On 7/12/06, Ian Hawthorn <[EMAIL PROTECTED]> wrote:
My 0.02c
The lilypond language is still evolving. Recent changes in syntax
have improved usablity. However at some point the improvements
to be gained by further tinkering with the syntax will be outweighed
by t
On 7/10/06, Fairchild <[EMAIL PROTECTED]> wrote:
Erik -
Thanks for contributing to this thread. It is attempting to deal with an
important unresolved issue: seamless evolutionary transitioning of ly files.
Your suggested solution requires "n" versions residing entirely in the
user's machine, w
epetitively adapt many ly files is overly burdensome.
- Bruce
-Original Message-
From: Simon Dahlbacka [mailto:[EMAIL PROTECTED]
Sent: Monday, July 10, 2006 10:24 AM
To: Fairchild
Cc: lilypond-user@gnu.org
Subject: Re: Evolutionary User Strategery
Br
- Bruce
-Original Message-
From: Erik Sandberg [mailto:[EMAIL PROTECTED]
Sent: Monday, July 10, 2006 3:12 AM
To: Fairchild
Cc: lilypond-user@gnu.org
Subject: Re: Evolutionary User Strategery
On 7/9/06, Fairchild <[EMAIL PROTECTED]> wrote:
> New scores could u
k Sandberg [mailto:[EMAIL PROTECTED]
Sent: Monday, July 10, 2006 3:12 AM
To: Fairchild
Cc: lilypond-user@gnu.org
Subject: Re: Evolutionary User Strategery
On 7/9/06, Fairchild <[EMAIL PROTECTED]> wrote:
> New scores could use new features and not have to work around the bugs
> of earlier v
On 7/9/06, Fairchild <[EMAIL PROTECTED]> wrote:
New scores could use new features and not have to work around the bugs of
earlier versions. Older scores that have been carefully tuned, compensating
for earlier bugs, would continue to produce the intended result without
having to be overhauled.
Hi, Bruce:
First, \header code could only be used once.
If this was true at some point [can someone confirm what version this
changed?], you could very easily -- with good abstracted code -- have
used three different score files (each with their own \header block).
Second, I found no way
D]; lilypond-user@gnu.org
Subject: Re: Evolutionary User Strategery
Bruce:
> Older scores that have been carefully tuned, compensating for
> earlier bugs
With all due respect, this implies something about Lilypond that
simply isn't true.
"Carefully tuned" is one thing. My sco
Bruce:
Older scores that have been carefully tuned, compensating for
earlier bugs
With all due respect, this implies something about Lilypond that
simply isn't true.
"Carefully tuned" is one thing. My scores are also carefully tuned;
from your work I've seen so far, I dare say I'm far m
versions.
- Bruce
-Original Message-
From: Erik Sandberg [mailto:[EMAIL PROTECTED]
Sent: Saturday, July 08, 2006 3:55 PM
To: Fairchild
Cc: lilypond-user@gnu.org
Subject: Re: Evolutionary User Strategery
On Saturday 08 July 2006 18:58, Fairchild wrote:
>
On Saturday 08 July 2006 18:58, Fairchild wrote:
> The 3.0 processor could note the 2.4 version flag and treat the ly file in
> the 2.4 way, maintaining upward compatibility without a need for
> convert-ly.
In what way would that be different from installing two different versions of
lily? If you
Bruce:
The 3.0 processor could note the 2.4 version flag and treat the ly
file in
the 2.4 way, maintaining upward compatibility without a need for
convert-ly.
Is that not exactly how software becomes bloatware!? =)
Best regards,
Kieren.
___
li
:08 AM
To: lilypond-user@gnu.org
Cc: Fairchild
Subject: Re: Evolutionary User Strategery
On Friday 07 July 2006 16:46, Fairchild wrote:
> LilyPonders -
>
> The only reasonable solution is to maintain upward compatibility in
> the LilyPond processor. New features should be added with
On Jul 8, 2006, at 3:07 AM, Erik Sandberg wrote:Let's say that you typeset a score in v2.4, and that lily, due to a bug, But, since 2.4 is a stable release, wouldn't there be the expectation that bugs were worked out before the next stable release is made, or that these "stable bugs" would be expe
On 7/8/06, Erik Sandberg <[EMAIL PROTECTED]> wrote:
On Friday 07 July 2006 16:46, Fairchild wrote:
> LilyPonders -
>
> The only reasonable solution is to maintain upward compatibility in the
> LilyPond processor. New features should be added without changing existing
> syntax. If it is deemed a
On Friday 07 July 2006 16:46, Fairchild wrote:
> LilyPonders -
>
> The only reasonable solution is to maintain upward compatibility in the
> LilyPond processor. New features should be added without changing existing
> syntax. If it is deemed absolutely necessary to change semantics or define
> co
I have been looking on and off at m4 macros for the sort of music I'm
typesetting. The advantage to this is that, if LilyPond changes
something, I might just have to change a macro definition or two and
re-compile.
Geoff
___
lilypond-user mailing list
Kieren MacMillan <[EMAIL PROTECTED]> writes:
> Hi, Bruce:
>> Users dealing with LilyPond as it evolves are presented with
>> difficult choices, none good.
> Well, "none good" might be a bit harsh... ;-)
> But your point is well taken.
>> If you can identify a better way, or have other comments, p
Hi, Bruce:
Users dealing with LilyPond as it evolves are presented with
difficult choices, none good.
Well, "none good" might be a bit harsh... ;-)
But your point is well taken.
If you can identify a better way, or have other comments, please
respond.
Always keep your note code (i.e., conten
Title: Evolutionary User Strategery
LilyPonders -
Users dealing with LilyPond as it evolves are presented with difficult choices, none good.
If one knows a score will be completed quickly, never be revisited, and components of the code structure never will be reused, the choice is easy
22 matches
Mail list logo
