date:20060712


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 the nuisance factor of having to frequently update/rewrite scores.
I don't think we are quite there yet as I still find the syntax awkward
for certain things. But it will happen at some point. Yes?

I think we need to look at tex as an example of the way forward.
I have tex files which I wrote back in the mid 80s which still
run just fine. The core of tex has been standard and static now for
a very long time. Yet tex continues to evolve via its package structure.
Maybe lilypond should look at doing this.

If the size of the codebase is a problem, a package structure would help.
I really have no need of weird medaevil musical notation, six line staves,
guitar tablature,  drum staves, strange clefs, notation for quarter tone
notes, etc etc. Others may not need the capacity to deal with polyphony
and lyrics which for me is essential. Yet every copy of lilypond comes
with everything.

A package structure would also help to manage the growth of the project.
Features could be added by adding packages, and it would be clear who
was supporting what.

In addition to its package structure, tex also uses style files. lilypond
could look to do the same. The templates now in the documentation
look to me to be embryonic style files, and seem to want to evolve in that
direction.

Finally, I'd like to eventually see something analogous to latex for
lilypond -
a package providing higher level syntax to make score writing less technical
for the average user.

Ian H


My 2 öre:

- A precondition for much of what you suggest, is a stable API: If we
decide a specific format for add-on packages, then all such packages
will break as soon as we change the API. Right now, I'm working on
introducing *two* new intermediate music representation formats to
lily. I see this as an indication that it will take some time before
it's time to define a stable API.

- Package size is not a problem, as long as it doesn't grow insanely
large (e.g., I wouldn't think it's sensible to multiply the package
size by the number of previously released versions).

- There are many problems to bridge; e.g., the syntax of lots of
features (lyrics, figured bass) are built into the .ly language, so
parser rules would have to be soft-codable.

- I hope you know about LSR, the lilypond snippet repository. So far
the LSR is rather small, which indicates that there is little public
interest in building add-on packages to lily. Currently, there seems
to exist few lily gurus (=people with so advanced knowledge that they
could have written LaTeX-style add-on-packages). So far I think it's
better if those people get involved in lily directly, and perhaps
contribute some snippets to the LSR. As long as LSR doesn't contain a
very large number of general utility .ly snippets, I don't think it
makes much sense to invent an add-on package system.

- I have the impression that Han-Wen is even more user-oriented than
me (i.e., he doesn't add features without proof that users need them).
So the best way of convincing _him_ that we need a system for add-on
packages, is probably to get involved and try to write some packages
yourself, using the (limited) mechanisms that exist.

Erik


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Evolutionary User Strategy - A Compromise

2006-07-12 Thread Colin Wilding



This is an important dilemma for many users, I think - we want to have all
the fixes and features in each new version, but find it frustrating when
music produced in earlier versions needs time-consuming manual editing to
upgrade.

Can I suggest a compromise?

I accept that Lilypond has been evolving rapidly and feel privileged to have
been able to use it (and contribute comments) during that evolution.

At some point, though, the evolution should slow down:  the developers
should feel happy with the basic structure and syntax and the users should
be able to expect that music written for today?s version will look the same
in tomorrow?s.

How about making a resolution that from version 3.0 onwards Lilypond will be
backwards-compatible:  in other words, the current version will correctly
display a file written in any earlier version 3.x without the need for
conversion.

For the developers that would mean retaining the behaviour of the earlier
versions, but only back as far as 3.0.  For the users it would mean that
once they had updated their files to 3.0 they could continue to use them
without further modification if they wished.

If the backward compatibilty subsequently became a burden then the
developers could start again with version 4.0 and write a convert-ly just
from 3.x to 4.0.


Colin

Fairchild wrote:
 
 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:
 save and share graphics only, dump the ly files for completed scores, and
 move on to the latest stable version.  I'm not that prescient.
 
 Constantly adopting the latest version allows use of the latest features,
 feedback helps the developers, and the developers provide support. 
 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.  
 
 It is tempting to select a stable version and stick with it.  Scores can
 be
 revisited easily.  Syntax and semantics are stable.  Downside: the feature
 set never gets better and support will fade away unless a sufficient
 number
 of users make the same choice and help each other.
 
 It is possible to maintain multiple LilyPond versions.  This allows
 revisiting old scores, but at a price.  The operational environment
 becomes
 more and more confusing as versions accumulate.
 
 I have coded tens of scores, most with version 2.4.6, and spent several
 hours attempting to move just one (a smaller one) of them to 2.8.5.  After
 using convert-ly and correcting for its errors, much remains to be done,
 especially to position the right text font.  Conclusion: repetitive
 conversion of scores is untenable.
 
 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
 conflicting syntax, provide for optional interpretations based on the
 version specified.  Older ly files should generate consistent results as
 LilyPond migrates.  More exhaustive regression tests are necessary.
 
 If you can identify a better way, or have other comments, please respond.
 
- Bruce
 
 
 
 ___
 lilypond-user mailing list
 lilypond-user@gnu.org
 http://lists.gnu.org/mailman/listinfo/lilypond-user
 
 
-- 
View this message in context: 
http://www.nabble.com/Evolutionary-User-Strategery-tf1906879.html#a5285941
Sent from the Gnu - Lilypond - User forum at Nabble.com.



___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

RE: Evolutionary User Strategy - A Compromise

2006-07-12 Thread Anthony Youngman

Something I thought of (having seen the comment about convert-ly using
grep ...)

I've got an on-off thing about writing a DATABASIC compiler (never mind)
and have come across a tool called Antlr. It is a compiler-compiler and
generates lexers, parsers and treeparsers.

IF someone wants to put the effort in, it may (or may not be) easy to
define various grammars to read in and chuck out different music
formats. It sounds as though a lot of the problems (like the swap
between   and   for example) would be easy. Especially given
lilypond's structure it looks like it would be fairly easy to define
grammars which can read in or chuck out different lily version syntaxes,
even the \addLyrics / \oldAddLyrics thing maybe.

The disadvantage of going down this route is I can see maintenance of
convert-ly becoming a big task. The advantage is that adding a new input
or output syntax is simply a matter of adding another grammar
definition. Only rarely are we likely to have to write a grammar to
transform convert-ly's internal representation - just when either (a) we
add a completely new 3rd-party format to the tool, or if there's a major
syntax change in lily that requires a paradigm shift ...

Cheers,
Wol

-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
.org] On Behalf Of Colin Wilding
Sent: 12 July 2006 11:01
To: lilypond-user@gnu.org
Subject: Re: Evolutionary User Strategy - A Compromise



This is an important dilemma for many users, I think - we want to have
all
the fixes and features in each new version, but find it frustrating when
music produced in earlier versions needs time-consuming manual editing
to
upgrade.

Can I suggest a compromise?

I accept that Lilypond has been evolving rapidly and feel privileged to
have
been able to use it (and contribute comments) during that evolution.

At some point, though, the evolution should slow down:  the developers
should feel happy with the basic structure and syntax and the users
should
be able to expect that music written for today?s version will look the
same
in tomorrow?s.

How about making a resolution that from version 3.0 onwards Lilypond
will be
backwards-compatible:  in other words, the current version will
correctly
display a file written in any earlier version 3.x without the need for
conversion.

For the developers that would mean retaining the behaviour of the
earlier
versions, but only back as far as 3.0.  For the users it would mean that
once they had updated their files to 3.0 they could continue to use them
without further modification if they wished.

If the backward compatibilty subsequently became a burden then the
developers could start again with version 4.0 and write a convert-ly
just
from 3.x to 4.0.


Colin

Fairchild wrote:
 
 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:
 save and share graphics only, dump the ly files for completed scores,
and
 move on to the latest stable version.  I'm not that prescient.
 
 Constantly adopting the latest version allows use of the latest
features,
 feedback helps the developers, and the developers provide support. 
 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.  
 
 It is tempting to select a stable version and stick with it.  Scores
can
 be
 revisited easily.  Syntax and semantics are stable.  Downside: the
feature
 set never gets better and support will fade away unless a sufficient
 number
 of users make the same choice and help each other.
 
 It is possible to maintain multiple LilyPond versions.  This allows
 revisiting old scores, but at a price.  The operational environment
 becomes
 more and more confusing as versions accumulate.
 
 I have coded tens of scores, most with version 2.4.6, and spent
several
 hours attempting to move just one (a smaller one) of them to 2.8.5.
After
 using convert-ly and correcting for its errors, much remains to be
done,
 especially to position the right text font.  Conclusion: repetitive
 conversion of scores is untenable.
 
 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
 conflicting syntax, provide for optional interpretations based on the
 version specified.  Older ly files should generate consistent results
as
 LilyPond migrates.  More exhaustive regression tests are necessary.
 
 If you can identify a better way, or have other comments, please
respond.
 
- Bruce
 
 
 
 ___
 lilypond-user mailing list

Colouring analysis brackets

2006-07-12 Thread Édouard Gilbert

Hi,

I'm not using Lilypond for a long time, so sorry if my question seems 
ridiculous.

I'm wondering if there is a way to print horizontal brackets in different 
colours
even when they start on the same note. Here come an example
(don't mind the notes or structure, they are nearly random).

%
\header
  {
title = Title
  }
  \score
  {
{
\once \override Staff.HorizontalBracket #'color = #red
d'\startGroup\startGroup\startGroup\startGroup\startGroup
d'\stopGroup ees'\startGroup e'\stopGroup\stopGroup e'\stopGroup
e'\stopGroup c'\startGroup\startGroup c'\startGroup\startGroup
c'\startGroup cis'\startGroup c'\stopGroup\stopGroup\stopGroup
c'\stopGroup\stopGroup g\startGroup a\startGroup
bes\stopGroup\stopGroup\stopGroup\stopGroup
   }
\layout
{
  \context
  {
\Staff \consists Horizontal_bracket_engraver
  }
}
  }

\version 2.8.5
%

As one can see, the five brackets opening on the first note are printed in red.
Is it possible to print, say, the second on in red, the fourth one in blue
and the others in black?

Thanks for your help,

Édouard



___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Quote within markup

Greetings -

I'm grateful for LilyPond, and for all the work a number of you are
putting into the program and the documentation. I can find answers to
most of my questions, although some take some experimentation. At this
stage, my biggest difficulty, I think, is understanding the syntax -
some commands come before notes, some are attached to the backs of
notes, and I'm not clear about the relationship between Scheme and
LilyPond.

My immediate problem is adding quotation marks within a markup. Nothing
I've tried works. LilyPond appears to interpret the quotation marks as a
command to keep the (my quoted) text together. My latest attempt:

e'''2 r2 ^\markup { \center-align { \line { (to aud.): A TRIO. }}}

Any suggestions would be appreciated.

Thanks for your time and attention,

Ralph


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Quote within markup

2006-07-12 Thread Geoff Horton


http://www.geoffhorton.com/lilypond.html#quote

On 7/12/06, Palmer, Ralph [EMAIL PROTECTED] wrote:

Greetings -

I'm grateful for LilyPond, and for all the work a number of you are
putting into the program and the documentation. I can find answers to
most of my questions, although some take some experimentation. At this
stage, my biggest difficulty, I think, is understanding the syntax -
some commands come before notes, some are attached to the backs of
notes, and I'm not clear about the relationship between Scheme and
LilyPond.

My immediate problem is adding quotation marks within a markup. Nothing
I've tried works. LilyPond appears to interpret the quotation marks as a
command to keep the (my quoted) text together. My latest attempt:

e'''2 r2 ^\markup { \center-align { \line { (to aud.): A TRIO. }}}

Any suggestions would be appreciated.

Thanks for your time and attention,

Ralph


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user




___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Newbie LilyPondTool installation help?

2006-07-12 Thread Joseph Anderson

Hello All,

I'm looking for a bit of help getting LilyPondTool up and running on MacOS X 
(10.4.7).

I've downloaded jEdit 4.2, and have the following plugins installed:

Console 4.2.6.3
ErrorList 1.4
Jakarta Commons 0.4.4
Latest Version Check 1.5
LilyPondTool 0.2.9
Mac Os Plugin 3.0
QuickNotepad 4.2
SideKick 0.3.4
Templates 3.3.0

I believe I'm running java 1.5, as from the terminal window, java -version 
reports back: java version 1.5.0_06.

I have LilyPond 2.9.10 installed--and it can be run from the command line, 
along with things like convert-ly.

The toolbar for LilyPondTool does appear in jEdit, however I'm having problems 
running LilyPond from within jEdit/LilyPondTool. With a simple test file, 
clicking the Convert to newer version button produces the following in 
BeanShell error:

java.lang.NoSuchMethodError: console.Console.setShell(Ljava/lang/String;)V
at lilytool.LilyToolPlugin.runCommand(LilyToolPlugin.java:409)
at lilytool.LilyToolPlugin.runCommandOnBuffer(LilyToolPlugin.java:438)
at lilytool.LilyToolPlugin.runCommandOnBuffer(LilyToolPlugin.java:430)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at bsh.Reflect.invokeOnMethod(Reflect.java:149)
at bsh.Reflect.invokeStaticMethod(Reflect.java:100)
at bsh.Name.invokeMethod(Name.java:872)
at bsh.BSHMethodInvocation.eval(BSHMethodInvocation.java:72)
at bsh.BSHPrimaryExpression.eval(BSHPrimaryExpression.java:102)
at bsh.BSHPrimaryExpression.eval(BSHPrimaryExpression.java:47)
at bsh.BSHAssignment.eval(BSHAssignment.java:77)
at bsh.BSHBlock.evalBlock(BSHBlock.java:130)
at bsh.BSHBlock.eval(BSHBlock.java:80)
at bsh.BSHBlock.eval(BSHBlock.java:46)
at bsh.BSHIfStatement.eval(BSHIfStatement.java:48)
at bsh.BSHBlock.evalBlock(BSHBlock.java:130)
at bsh.BSHBlock.eval(BSHBlock.java:80)
at bsh.BSHBlock.eval(BSHBlock.java:46)
at bsh.BSHIfStatement.eval(BSHIfStatement.java:48)
at bsh.BSHBlock.evalBlock(BSHBlock.java:130)
at bsh.BSHBlock.eval(BSHBlock.java:80)
at bsh.BshMethod.invokeImpl(BshMethod.java:349)
at bsh.BshMethod.invoke(BshMethod.java:246)
at bsh.BshMethod.invoke(BshMethod.java:171)
at org.gjt.sp.jedit.BeanShell.runCachedBlock(BeanShell.java:523)
at org.gjt.sp.jedit.BeanShellAction.invoke(BeanShellAction.java:76)
at org.gjt.sp.jedit.gui.InputHandler.invokeAction(InputHandler.java:229)
at org.gjt.sp.jedit.jEdit$3.invokeAction(jEdit.java:2910)
at 
org.gjt.sp.jedit.EditAction$Wrapper.actionPerformed(EditAction.java:216)
at 
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882)
at 
javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202)
at 
javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420)
at 
javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258)
at 
javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234)
at 
java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231)
at 
java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231)
at 
java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231)
at java.awt.Component.processMouseEvent(Component.java:5554)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3126)
at java.awt.Component.processEvent(Component.java:5319)
at java.awt.Container.processEvent(Container.java:2010)
at java.awt.Component.dispatchEventImpl(Component.java:4021)
at java.awt.Container.dispatchEventImpl(Container.java:2068)
at java.awt.Component.dispatchEvent(Component.java:3869)
at 
java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866)
at java.awt.Container.dispatchEventImpl(Container.java:2054)
at java.awt.Window.dispatchEventImpl(Window.java:1774)
at java.awt.Component.dispatchEvent(Component.java:3869)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
at 
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269)
at 
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176)
at

RE: Quote within markup

 Geoff -

I tried

e'''2 r2 ^\markup { \center-align { \line { (to aud.): \A TRIO.\
}}}

and got

error: syntax error, unexpected $undefined
e'''2 r2 ^\markup { \center-align { \line { (to aud.): 
   \A
TRIO.\ }}}

Ralph

-Original Message-
From: Geoff Horton [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 12, 2006 8:23 AM
To: Palmer, Ralph
Cc: lilypond-user@gnu.org
Subject: Re: Quote within markup

http://www.geoffhorton.com/lilypond.html#quote

On 7/12/06, Palmer, Ralph [EMAIL PROTECTED] wrote:
 Greetings -

 My immediate problem is adding quotation marks within a markup. 
 Nothing I've tried works. LilyPond appears to interpret the quotation 
 marks as a command to keep the (my quoted) text together. My latest
attempt:

 e'''2 r2 ^\markup { \center-align { \line { (to aud.): A TRIO. }}}

 Any suggestions would be appreciated.

 Thanks for your time and attention,

 Ralph





___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Re: Mixing text and notation

2006-07-12 Thread Nicolas Prömper

Hi Nicolas,

I want to have a preambel, that is split in two columns. So, the result should 
look like this:

title
subtitle

preamble left   | preamble right

Here comes the score

I couldn't find any formatting for markup, that splits the text in two columns. 
I assume, that this can only be done with a word processing.

But anyway, thanks for your answer.

Regards 
Nick

 
 Why not let LilyPond take care of this?
 Have you Read The Fine Manual, section 8.1.4 Text Markup?
 
   Text can also be placed on its own, away from any score block.
 
   markup{ Here is some text. }
 
 
 ___
 lilypond-user mailing list
 lilypond-user@gnu.org
 http://lists.gnu.org/mailman/listinfo/lilypond-user
 

--- original Nachricht Ende 



___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Quote within markup

2006-07-12 Thread Geoff Horton


e'''2 r2 ^\markup { \center-align { \line { (to aud.): \A TRIO.\


Backwards :)

\A TRIO\'

ought to do it.

Geoff


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Re: Mixing text and notation

2006-07-12 Thread Geoff Horton


I want to have a preambel, that is split in two columns.


\markup {
 \fill-line {
   \hspace #1.0 % add more of these at the beginning and end
   \hspace #1.0 % to move the columns closer together
   \column {
 The first column
 goes here
   }
   \hspace #3
   \column {
 The second column
 goes here
   \hspace #1.0 % Delete these at beginning and end
   \hspace #1.0 % if the columns are wide and you need room
   }
 }
}
==

Off the top of my head, I don't know if it's possible to get the two
columns to flow automatically.

Geoff


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Evolutionary User Strategy - A Compromise

On Wednesday 12 July 2006 12:00, Colin Wilding wrote:
 This is an important dilemma for many users, I think - we want to have all
 the fixes and features in each new version, but find it frustrating when
 music produced in earlier versions needs time-consuming manual editing to
 upgrade.

 Can I suggest a compromise?

 I accept that Lilypond has been evolving rapidly and feel privileged to
 have been able to use it (and contribute comments) during that evolution.

 At some point, though, the evolution should slow down:  the developers
 should feel happy with the basic structure and syntax and the users should
 be able to expect that music written for today?s version will look the same
 in tomorrow?s.

What do you mean by 'the same'? Is it OK if the output suddenly looks better 
because a bug has been fixed?
If yes, then you still have the problem that an upgrade may break your tweaks 
that work around layout bugs.
If no, then development will be very difficult because all bugs have to be 
preserved.

If there's sufficient community interest in maintaining and developing a 
conservative version of lilypond, then anyone can make a fork; however, I 
doubt any of the current developers would join. Lily is currently at a pretty 
early stage of development IMHO.

 How about making a resolution that from version 3.0 onwards Lilypond will
 be backwards-compatible:  in other words, the current version will
 correctly display a file written in any earlier version 3.x without the
 need for conversion.

I think 2.4 files are fairly forward compatible; there have been no major 
changes that I know of. 

There's also the question of what you mean by compatibility: Very advanced 
tweaks usually rely on the way lily's internals are organised, which may 
change over time. Since lily contains a Turing-complete programming language, 
for some language updates it is thereby _impossible_ to create a script that 
upgrades _all_ .ly files perfectly. There are also deprecated features that 
are dropped sometimes, this causes a kind of backward incompatibility.

-- 
Erik



___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Evolutionary User Strategy - A Compromise

On Wednesday 12 July 2006 12:59, Anthony Youngman wrote:
 Something I thought of (having seen the comment about convert-ly using
 grep ...)

It's not using grep, but it relies heavily on regexps (so it can somewhat 
fairly be compared to sed).

 I've got an on-off thing about writing a DATABASIC compiler (never mind)
 and have come across a tool called Antlr. It is a compiler-compiler and
 generates lexers, parsers and treeparsers.

 IF someone wants to put the effort in, it may (or may not be) easy to
 define various grammars to read in and chuck out different music
 formats. It sounds as though a lot of the problems (like the swap
 between   and   for example) would be easy. Especially given
 lilypond's structure it looks like it would be fairly easy to define
 grammars which can read in or chuck out different lily version syntaxes,
 even the \addLyrics / \oldAddLyrics thing maybe.

I'd rather have a look at parsing expression grammars, see: 
http://en.wikipedia.org/wiki/Parsing_expression_grammar
Seems to combine simplicity of regexps with the power of CFGs. Doesn't seem to 
be widely implemented though.

Another way could be to go via the syntax expressions I'm working on: Instead 
of applying operations on .ly input, we could apply them to the parser's 
output, and then use some built-in version specific mechanism to convert 
finished files back to .ly. I thikn this would be both more reliable than 
convert-ly, and possibly easier to maintain, but some text formatting might 
be lost unless the syntax-expression-ly conversion is designed very 
carefully. Depending on how macros will be implemented, commands like 
\relative may be lost as well.

-- 
Erik



___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Evolutionary User Strategy - A Compromise

2006-07-12 Thread Simon Dahlbacka

On 7/12/06, Erik Sandberg [EMAIL PROTECTED] wrote:
On Wednesday 12 July 2006 12:59, Anthony Youngman wrote: Something I thought of (having seen the comment about convert-ly using grep ...)It's not using grep, but it relies heavily on regexps (so it can somewhat
fairly be compared to sed). I've got an on-off thing about writing a DATABASIC compiler (never mind) and have come across a tool called Antlr. It is a compiler-compiler and generates lexers, parsers and treeparsers.
 IF someone wants to put the effort in, it may (or may not be) easy to define various grammars to read in and chuck out different music formats. It sounds as though a lot of the problems (like the swap
 between   and   for example) would be easy. Especially given lilypond's structure it looks like it would be fairly easy to define grammars which can read in or chuck out different lily version syntaxes,
 even the \addLyrics / \oldAddLyrics thing maybe.I'd rather have a look at parsing _expression_ grammars, see:http://en.wikipedia.org/wiki/Parsing_expression_grammar
Seems to combine simplicity of regexps with the power of CFGs. Doesn't seem tobe widely implemented though.another possibility might be to upgrade convert-ly to use something like pyparsing (
http://http://pyparsing.wikispaces.com/). Still, you can't make a 100% perfect converter../S
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

RE: Evolutionary User Strategy - A Compromise

2006-07-12 Thread Anthony Youngman

I don't really understand grammars etc (which is why my DATABASIC thing
is on/off :-).

But from my experience with Antlr, I don't see why you should lose
stuff. Your PEG article mentions ASTs. I don't see that converting a .ly
file into an AST can be that hard. So, for example, we write a Antlr
grammar that creates a lexer/parser that turns the .ly into an AST. We
now write another grammar that converts the AST to a .ly file.

Provided we freeze the AST layout, it's dead easy to handle things like
the   /   switch - the input grammar reads  and the output
grammar writes  etc.

The \addLyrics problem is a bit harder. I don't know whether we could
parse both old and new versions into the same AST, but if we couldn't, a
treeparser to convert between ASTs isn't that hard. Antlr does things
like converting between Java and C# ... !!!

Anyways, I would expect that we could share one AST between several
incompatible .ly variants of lily, and within that, an either
direction transform would be easy. It also means that adding import (or
export) of other formats would be easy - to import, write a parser
grammar to read the other format and a treeparser to transform the
resulting AST to the lily version. For export, go the other way. But it
modularises everything.

And you wouldn't lose things like \relative because you're using a pure
lexer/parser setup, that wouldn't even understand what \relative was :-)

I might play with this when I get my hands on Antlr 3, but don't bank on
it.

Cheers,
Wol

-Original Message-
From: Erik Sandberg [mailto:[EMAIL PROTECTED] 
Sent: 12 July 2006 13:55
To: lilypond-user@gnu.org
Cc: Anthony Youngman
Subject: Re: Evolutionary User Strategy - A Compromise

On Wednesday 12 July 2006 12:59, Anthony Youngman wrote:
 Something I thought of (having seen the comment about convert-ly using
 grep ...)

It's not using grep, but it relies heavily on regexps (so it can
somewhat 
fairly be compared to sed).

 I've got an on-off thing about writing a DATABASIC compiler (never
mind)
 and have come across a tool called Antlr. It is a compiler-compiler
and
 generates lexers, parsers and treeparsers.

 IF someone wants to put the effort in, it may (or may not be) easy to
 define various grammars to read in and chuck out different music
 formats. It sounds as though a lot of the problems (like the swap
 between   and   for example) would be easy. Especially given
 lilypond's structure it looks like it would be fairly easy to define
 grammars which can read in or chuck out different lily version
syntaxes,
 even the \addLyrics / \oldAddLyrics thing maybe.

I'd rather have a look at parsing expression grammars, see: 
http://en.wikipedia.org/wiki/Parsing_expression_grammar
Seems to combine simplicity of regexps with the power of CFGs. Doesn't
seem to 
be widely implemented though.

Another way could be to go via the syntax expressions I'm working on:
Instead 
of applying operations on .ly input, we could apply them to the parser's

output, and then use some built-in version specific mechanism to convert

finished files back to .ly. I thikn this would be both more reliable
than 
convert-ly, and possibly easier to maintain, but some text formatting
might 
be lost unless the syntax-expression-ly conversion is designed very 
carefully. Depending on how macros will be implemented, commands like 
\relative may be lost as well.

-- 
Erik


*  *

This transmission is intended for the named recipient only. It may contain 
private and confidential information. If this has come to you in error you must 
not act on anything disclosed in it, nor must you copy it, modify it, 
disseminate it in any way, or show it to anyone. Please e-mail the sender to 
inform us of the transmission error or telephone ECA International immediately 
and delete the e-mail from your information system.

Telephone numbers for ECA International offices are: Sydney +61 (0)2 8272 5300, 
Hong Kong + 852 2121 2388, London +44 (0)20 7351 5000 and New York +1 212 582 
2333.

*  *


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Decomposing Lilypond-book for makefile optimization?

2006-07-12 Thread Jeff Smith

Hi gang. I'm using lilypond-book to render some musical diagrams into a latex document. I'm having a problem for which I need help to solve.My document has about 30 short musical compositions that are included as diagrams. They are also full compositions in their own right, so I want to use the stand-alone .ly files within my doc. (I hate the idea of having two versions of each .ly) So far so good. I can use \lilypondfile in my latex doc, preprocess with lilypond-book and everything is happy.
Except...My document is quite lengthy. Every time I make a change to the master doc (the .lytex source), lilypond-book robotically goes along and recompiles all the lilypond files, even though they haven't changed. Needless to say, this creates a LOT of extra compile time, which I would rather avoid. Furthermore, due to the document's dependency on all the .ly files, if I only change one of those, then lilypond-book still runs, and stomps on all the intermediate latex files, which causes EVERYTHING to rebuild.
I have a clumsy workaround, in which I skip lilypond-book. Instead, I use \includegraphics in my .tex file, and I compile the .ly files separately, using some spiffy makefile wizardry to detect when they have changed. This works just fine.
Except...To compile my .ly files into a graphics format suitable for the \includegraphics statement, I am currently doing lilypond --png file.ly, then passing that to an autocrop tool that crops off the header, footer and borders, leaving me with an isolated block of music, much like the output I get from lilypond-book, which is then converted to EPS format. The problem is that, by going through PNG format, I get all kinds of unslick, grainy artifacts in the final EPS.
I've also tried to render using lilypond --ps file.ly which produces usable looking output, but it is still embedded in a full-page image. When I autocrop that, it just ends up looking horrible.
What I'd LIKE to do, is stick with my fancy makefile to compile the various .ly files as necessary, but use the same pipileine that lilypond-book uses to spit out its cropped EPS format images. I know it must be possible, because lilypond-book is doing it, but I don't speak python well enough to unravel HOW it does it.
Can anybody provide some pointers on how to get lilypond to spit out cropped EPS files? Are there some hidden command line switches that might do it? -- Jeff SmithComputer Science Dept.
University of Saskatchewan
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Quote within markup

2006-07-12 Thread Daniel Johnson


Palmer, Ralph wrote:

e'''2 r2 ^\markup { \center-align { \line { (to aud.): A TRIO. }}}
Why not use curly quotes?  They look more professional and are not 
interpreted as special characters by the parser.



___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

RE: Quote within markup

Bingo! Thanks, Geoff. I should have figured out that it was backwards; I
think frustration had something to do with it. 

-Original Message-
From: Geoff Horton [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 12, 2006 9:42 AM
To: Palmer, Ralph
Cc: lilypond-user@gnu.org
Subject: Re: Quote within markup

 e'''2 r2 ^\markup { \center-align { \line { (to aud.): \A TRIO.\

Backwards :)

\A TRIO\'

ought to do it.

Geoff



___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Evolutionary User Strategy - A Compromise

On Wednesday 12 July 2006 17:22, Anthony Youngman wrote:
 I don't really understand grammars etc (which is why my DATABASIC thing
 is on/off :-).

 But from my experience with Antlr, I don't see why you should lose
 stuff. Your PEG article mentions ASTs. I don't see that converting a .ly
 file into an AST can be that hard. So, for example, we write a Antlr
 grammar that creates a lexer/parser that turns the .ly into an AST. We
 now write another grammar that converts the AST to a .ly file.

A problem here is code duplication; it takes some effort to maintain two 
parsers instead of one. I think it will be difficult to automatically test 
that the current antlr parser corresponds well with the actual grammar the 
current lilypond version uses.

I have been thinking about moving lily's entire parser out to Scheme; this way 
we could keep one old parser for each version, and use it to generate an AST, 
which then is converted nicely using rules written in Scheme (Scheme rocks 
when it comes to tree manipulation). I'm not sure if it's possible though.

BTW: Will your solution handle whitespace nicely?

-- 
Erik


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

RE: Quote within markup

Hi, Daniel Johnson -

I'm using jEdit. The default font looks like Times New Roman; at least,
it's seriffed. Character encoding is set to UTF-8. I cannot find any
place to 1) set the font (typeface); 2) find an insert symbol utility;
or 3) find a place to set curly quotes.

Anyone out there using jEdit who can point me in the right direction?

Thanks,

Ralph 

-Original Message-
From: Daniel Johnson [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 12, 2006 1:00 PM
To: Palmer, Ralph
Cc: lilypond-user@gnu.org
Subject: Re: Quote within markup

Palmer, Ralph wrote:
 e'''2 r2 ^\markup { \center-align { \line { (to aud.): A TRIO. }}}
Why not use curly quotes?  They look more professional and are not
interpreted as special characters by the parser.




___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Quote within markup

2006-07-12 Thread Kieren MacMillan


Hi, Ralph


3) find a place to set curly quotes.


If you are on Mac OS, just type option-[ for “ (left double  
typographer's quote) and option-shift-[ for ” (right d.t.q.).

For other OSes, perhaps someone else can help on a shortcut.

Best,
Kieren.

___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Mixing text and notation

2006-07-12 Thread Nicolas Sceaux

Geoff Horton [EMAIL PROTECTED] writes:

 I want to have a preambel, that is split in two columns.

 \markup {
   \fill-line {
 \hspace #1.0 % add more of these at the beginning and end
 \hspace #1.0 % to move the columns closer together
 \column {
   The first column
   goes here
 }
 \hspace #3
 \column {
   The second column
   goes here
 \hspace #1.0 % Delete these at beginning and end
 \hspace #1.0 % if the columns are wide and you need room
 }
   }
 }

I'd rather use \justify with overrided line-width.

\markup \fill-line {
  \override #'(line-width . 50) \justify {
The GNU Hurd is a computer operating system kernel. It consists of
a set of servers (or daemons, in Unix-speak) that work on top of
either the GNU Mach microkernel or the L4 microkernel; together,
they form the kernel of the GNU operating system. It has been
under development since 1990 by the GNU Project and is distributed
as free software under the GPL. The Hurd aims to surpass Unix
kernels in functionality, security, and stability, while remaining
largely compatible with them. This is done by having the Hurd
track the POSIX specification, while avoiding arbitrary
restrictions on the user.
  }
  \hspace #2 % minimum space between the two columns
  \override #'(line-width . 50) \justify {
\HURD\ is an indirectly recursive acronym, standing for
\HIRD of Unix-Replacing Daemons\, where \HIRD\ stands for
\HURD of Interfaces Representing Depth\. It is also a play of
words to give \herd of gnus\ reflecting how it works.
[wikipedia]
  }
}


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Mixing text and notation


Nicolas Prömper wrote:

I want to include a short text in a score (a kind of preamble) with an advanced 
formatting.
I'd like to use a word processing to create and format the text, and include 
the result in my score.


Creating this text in lilypond is probably the easiest solution; other 
people have helped you with this.


If you really want to use another program, use that program (or other 
programs) to create an .eps file.  These files can be included in a 
lilypond score with \markup{ \epsfile }.


Cheers,
- Graham


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Quote within markup

2006-07-12 Thread Daniel Johnson


Palmer, Ralph wrote:

Hi, Daniel Johnson -

I'm using jEdit. The default font looks like Times New Roman; at least,
it's seriffed. Character encoding is set to UTF-8. I cannot find any
place to 1) set the font (typeface); 2) find an insert symbol utility;
or 3) find a place to set curly quotes.

Anyone out there using jEdit who can point me in the right direction?

Thanks,

Ralph 
  
I'm guessing you're using Windows.  In that case, you have 2 possible 
solutions:
1. Start-All Programs-Accessories-System Tools-Character Map (copy  
paste)
2. Alt-0147 for left quotes, Alt-0148 for right quotes. Hold down Alt 
while you type the numbers from the numeric keypad on the right side of 
the keyboard, then release Alt when finished.



___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Evolutionary User Strategy - A Compromise


Erik Sandberg wrote:
There's also the question of what you mean by compatibility: Very advanced 
tweaks usually rely on the way lily's internals are organised, which may 
change over time. Since lily contains a Turing-complete programming language, 
for some language updates it is thereby _impossible_ to create a script that 
upgrades _all_ .ly files perfectly.


Actually, doesn't this mean that we can _always_ upgrade _all_ .ly files 
perfectly?  Since lily contains a Turing-complete language, we just need 
to write a universal Turing machine which emulates the behavior of 2.4 
(or whatever).  Then convert-ly takes 2.4, adds our Turing machine, and 
presto, we have a .ly file which compiles under 2.8.


Of course, that .ly file is probably about 20 megabytes in size, and 
would take a huge amount of time to run... but it would work!  :)


Cheers,
- Graham


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Decomposing Lilypond-book for makefile optimization?


Jeff Smith wrote:
My document is quite lengthy. Every time I make a change to the master 
doc (the .lytex source), lilypond-book robotically goes along and 
recompiles all the lilypond files, even though they haven't changed.


This is a bug; lilypond-book shouldn't recompile anything unnecessarily. 
 What version of lilypond are you using, on which OS, and  what 
command-line arguments are you using?  Does it make a difference if you 
run lilypond-book from your output directory?  (ie don't use --out/ or 
--output/ or whatever that command is )



I can't help with your other questions... nor can I really help with 
debugging lilypond-book... but answering these questions may help other 
people discover the problem faster.  :)


Cheers,
- Graham


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: I have made some clarification on the \octave directive