[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Parse error attempting to resize font (1.4.12/Windows)

From: Hans Forbrich
Subject: Re: Parse error attempting to resize font (1.4.12/Windows)
Date: Sun, 28 Apr 2002 19:15:48 -0600

Mats Bengtsson wrote:

> >... I've been using the online manual and tutorial,
> > as well as mutopia to 'learn  by example'.
> As you say, many of the Mutopia examples are written
> for fairly old Lilypond versions. You can update some
> of the features using the program convert-ly, but if
> you want a better set of examples to learn from, take
> a look at the files in the directories input/test/ and
> input/regression/ included both in the source code tree
> and somewhere in the precompiled packages. You can actually
> view many of them in the document "Regression test" on the
> web site.

Excellent suggestion.

The Tutorial was great for the absolute basics, but I didn't really know where
to go from there.  I found some sheet music on Mutopia, found that it matched
what I needed and used that as a template.  Since then I've read about
convert-ly and will definitely be using that.

> > There is a lot of theory
> > behind this that I'm not familiar with - won't be until I get Linux up
> > again, stuff like moving grobs manually to avoid collisions the system
> > gave up on (probably my fault).
> Well, it's got nothing to do with Linux or Windows. If you send
> a short example to the mailing list illustrating the problem,
> I'm sure someone will give you a hint in the right direction.

I concur.  It's just that getting Linux up is more of a priority than getting
some of the finer elements right now.  Once that is done, I'll have the time
to get into LilyPond seriously.

> > I note some of the mutopia examples
> > I've referred to use a lot of deprecated syntax.. However I do recall
> > the online (static) manual mentions 'simultaneous' and {} as shorthand.
> Of course, you want to stick to the shorthand as soon as you do
> any serious typesetting.
> > One thing I'm interested in - has anyone thought of using XML as a
> > neutral definition language in front of LilyPond?  Potentially more
> > verbose, but there are potential benefits as well.  (Probably will start
> > this as a separate thread if I get any takers on this question.)
> Developing a definition language is a tedious task, the current
> Lilypond input language has evolved gradually over many years.
> It would certainly be possible to develop another syntax but I
> must admit I don't see any benefits. In my opinion, one of the
> major advantages of Lilypond is that you can enter the music fairly
> quickly without having to spoil you arm using the mouse, so
> verbosity is a clear disadvantage in this case, unless it could
> lower the learning threshold for a beginner. I don't see how XML
> could help in that respect.

I see no basic problem with the fundementals for LilyPond, and I am quite
enthusiastic about it.

However, I've been around markup languages (MLs) since the early 80s and find
them quite useful.  XML was created to separate the content from the
formatting, ultimately allowing developers to create special format handlers.
The examples I've seen in LilyPond tend to require mixing content with
formatting.  I also noted that raw input is quick, but debugging, especially
format issues, takes a while;  that was actually the reason why I started
thinking about this.

I also agree that a well designed language that separates the content (melody,
etc.) from the formatting requirements could be a challenge to create.
LilyPond already provides the basis for such a language so it's probably not a
huge leap, primarily verbosity and syntax.  However, some of the benefits are:

1) Input could be almost as rapid as LilyPond
2) A definition language enforces syntax, therefore a strict type checker
could be built at input time
3) It could provide additional transparency between LilyPond and other
systems, including Midi, ABC, etc.
4) XML inherently allows rapid access to, and extraction of, subtrees.
Subtrees could be visualized as 'parts' or 'voices', therefore extracting and
printing individual parts should become easier
5) You can suppress the formatting without altering input, allowing rapid
display of the music.

Since all of these things can be done already, although in some cases using
'workarounds', in some ways this discussion becomes philosophical. I have
noticed in the internet that there are some attempts at creating an XML
definition, so we will eventually end up with either raw XML input to LilyPond
or an XML2Ly converter.  (I'd rather see this community have input to the

Just some thoughts.  If this discussion carries on, I suggest we put it in a
separate subject line.


> Regards
>   /Mats

reply via email to

[Prev in Thread] Current Thread [Next in Thread]