[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GLISS] basics
From: |
Joseph Rushton Wakeling |
Subject: |
Re: [GLISS] basics |
Date: |
Wed, 26 Sep 2012 14:43:41 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 |
On 26/09/12 09:19, Janek Warchoł wrote:
This is a good idea in itself, but i'm afraid we'll drown in the flood
of suggestions if we ask this question now. Currently we want to
focus on syntax alone.
I do understand that, it's just that I think that proposals for syntax changes
make more sense when considered in the broader context of the notation you want
to support. I wasn't proposing asking it as a mailing-list question, more as a
project that could probably be handled by relatively few people working from
musical notation texts.
The reason I think that's important is because without considering the
notational scope, syntax proposals can easily exclude a range of desirable
features. The existing \tempo command is a good example. It makes perfect
sense for simple metronome marks, but excludes a whole host of widely-used tempo
change indications.
It turns out (as per David's earlier email) that it's possible to have a syntax
which allows all of those possibilities, that isn't much more complex for the
simple use-case, _and_ is easier on the parser. But without considering that
broader scope of notation, it would be easy to say, "Hey, this is just
complicating the existing syntax for the sake of the parser, why not make the
parser do the work and keep it simple for users?"
I mean, some things you mentioned don't need
syntax changes, for example this
Fair point, some of these things are best characterized as limits in the
interpretation of syntax rather than in syntax per se. I don't think at this
point it's useful for me to respond in detail on the particular examples, though
I can do so if you like.
Don't get me wrong - i agree with you that we need to check whether
Lilypond syntax can be used to express all musical notations as
effortlessly as possible. I just mean that "this can be expressed in
Lily syntax" doesn't equal "this notation is supported by LilyPond".
Sure, but that's kind of what I was getting at -- you want to separate out the
cases where the syntax is genuinely inadequate, where it's theoretically
adequate but the internal data structures or engraving algorithms are
inadequate, where the syntax is unnecessarily verbose, or where it's simply
difficult to find out about the syntax.
That info then gives you the basis to make rigorous changes to the syntax. For
example, it lets you know that proposed changes to the \tempo command don't just
benefit the parser -- they also expand the range of notation it can cover.
My idea was to ask about this in fourth question:
"what do you find difficult to express in LilyPond syntax? For
example, things that need to be done by moving something manually
instead of describing the logic behind it."
Probably the question could be formulated better.
I think the question is a good one to ask. As per my examples, you'll surely
find quite a few where the real issue is not syntax but the engraving process,
or simply cases where users aren't aware of the existing solutions.
But the real concern I have is that I don't think that members of the Lilypond
user list are necessarily representative of the range of engraving activity that
Lilypond needs to support. That's the other reason I suggested a systematic
process of checking syntax/engraving support vs. a broad set of musical notation.
I don't have a copy of the Elaine Gould book you mentioned earlier, but
that, together with Keith Stone and Gardner Read might be a good starting
point.
Yes. As i'm reading "Behind Bars", i'm noticing things that can't be
expressed in Lily syntax easily. I will make a report about this.
I don't have other books, though.
I can send you a copy of the couple of papers Keith Stone wrote on contemporary
notation -- these are a precursor to his book. They're less comprehensive but
nevertheless useful.
I don't think i have time to do the engraving myself. That's why we
should ask users, who in their collective wisdom had encountered
almost anything :)
Well, I'm not suggesting engraving whole works. Selected snippets should be
adequate. Besides the obvious "contemporary composer complex stuff", there are
also some surprisingly simple notations which show up here -- e.g. Ferneyhough
frequently has hairpins which last until the end of the note and have a
concluding dynamic value; that dynamic value falls at the end of the hairpin
rather than the beginning of the subsequent note (if you get me).
See e.g.
http://soundandmusic.org/thecollection/files/scores/28724w.pdf in for example
bar 4, Violin 3 (although there are plenty of other examples in the score).
That seems to me a notation for which there genuinely isn't a solution in
Lilypond syntax or internals, although you could probably fake it with careful
use of parallel space notation.
- Re: [GLISS] basics, (continued)
Re: [GLISS] basics, Joseph Rushton Wakeling, 2012/09/25
- Re: [GLISS] basics, Janek Warchoł, 2012/09/26
- Re: [GLISS] basics, David Kastrup, 2012/09/26
- Re: [GLISS] basics, Janek Warchoł, 2012/09/26
- Re: [GLISS] basics, David Kastrup, 2012/09/26
- Re: [GLISS] basics, Janek Warchoł, 2012/09/26
Re: [GLISS] basics,
Joseph Rushton Wakeling <=
Re: [GLISS] basics, Janek Warchoł, 2012/09/27
Re: [GLISS] basics, Joseph Rushton Wakeling, 2012/09/27