lilypond-devel
[Top][All Lists]
Advanced

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

Re: [GLISS] why the hell all this fuss


From: Janek Warchoł
Subject: Re: [GLISS] why the hell all this fuss
Date: Fri, 7 Sep 2012 00:50:14 +0200

On Thu, Sep 6, 2012 at 9:55 AM, David Kastrup <address@hidden> wrote:
> Janek Warchoł <address@hidden> writes:
>> Example: hairpins.  There is no convenient way of specifying hairpins
>> that don't align with the notes (you have to use spacer rests, which
>> is bad for a number of reasons).  We need to have a convenient way.
>> Adding this will be a syntax change, so let's do it now instead of
>> later.
>
> I don't see why you should not be able to do this using music functions.
>
>> Another example: vertical hairpins attached to arpeggios (Elaine Gould
>> shows them).  I don't think we have a simple way of extending our
>> syntax to express them - some basic design principles would have to be
>> changed a bit, i suppose.  So let's change them now.
>
> I don't see why you should not be able to do this using music functions.

Hmm.  You may be absolutely right.  Maybe all we need is to write such
functions and ship them with LilyPond!
There's one thing worth clarifying: when i say "syntax changes", i
mean "changes in how user input looks like".  So a renaming of a
command is a syntax change to me (despite the fact that no grammar
rules change).
That's probably confusing - what word should i use when i mean
"changes in how user input looks like"?

On Thu, Sep 6, 2012 at 10:05 AM, David Kastrup <address@hidden> wrote:
> Janek Warchoł <address@hidden> writes:
>> Hmm.  Maybe.
>> It would be useful for other kinds of spanners, and also articulations
>> (for example to place a turn during a note).
>> Would creating macros for all of them be feasible? (maybe i miss
>> something obvious?)
>
> Creating a single macro that can be used on all of them.

My only question is whether current syntax rules would allow such
macro to be concise and easy to use.  I'm probably talking stupid -
sorry for that - it's just that i don't have experience in this area
(extending LilyPond), and at the same time i'm very concerned about
the results of our discussion.  Could you give me an example of how
such macro could look like?  It's entirely possible that we already
have all necessary tools, and i'm too dumb to use them.

>> My rough idea would look something like this
>> (this is just a musing, not a proposal for discussion yet):
>>
>> { b2 \<@0.5 a2 address@hidden } meaning { << b1 { s2 \< s2 \! } >> }
>
> Looks like a case of the cure being worse than the problem.  Apart from
> not being related in any obvious manner.

I'm not sure i understand what you had in mind.

>> Not quite :)  \arpeggioUpWithHairpinDown and
>> \arpeggioUpWithPianoFirstThenHairpinToPianissimo don't sound like fun!
>> ;)
>
> Commands can take arguments.

Wouldn't we have another instance of problematic optional arguments if
we did this that way?  Like, if \arpeggio was allowed to take an
optional dynamic argument, we'd not know whether { c\arpeggio\< }
meant that the hairpin affects the arpeggio or that it's just a
hairpin attached to c.
(this may be a very stupid question)

> You are thinking in ways of PDF.  LilyPond is meant for expressing
> music.  If we build in syntax like that, it should carry musical
> meaning, not just create pretty images.  How do you "attach" things like
> that to MIDI or MusicXML?

Hmm.  Aren't some things simply impossible to reasonably export to
MIDI?  As for musicXML, i don't know how it works "inside".
It's totally possible that there's a better way of doing this than
what i proposed - it's just something that came to my mind and seemed
quite logical.  If you have some alternative idea, post it! I'd be
glad to wrap my head around it.  Meanwhile, i'll continue collecting
examples of "objects attached to other objects" so that we can have a
good overview of what's needed.

Thanks for your patience, David! (and all of you, too!)
Janek



reply via email to

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