lilypond-devel
[Top][All Lists]
Advanced

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

Re: Thinking about another disruptive change


From: David Kastrup
Subject: Re: Thinking about another disruptive change
Date: Tue, 15 Nov 2011 13:14:23 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux)

Reinhold Kainhofer <address@hidden> writes:

> Am 2011-11-15 10:49, schrieb David Kastrup:
>> The "principle of lazy complication" would keep material as simple as
>> feasible until a more complicated version is asked for.
>>
>> That is, when a music function asks for a "scheme?" argument and the
>> input is just c', it gets a pitch.  If it asks for a "ly:music?" event,
>> it gets a NoteEvent (not an EventChord).  If it asks for an EventChord,
>> it gets one.
>> [...]
>>
>> All in all, such a change should make programming and inspecting data
>> structures much more straightforward, and particularly save the
>> programmer from the "let's see what complex structures Lilypond creates
>> from simple input and devise a scheme how to get at the simple things we
>> actually wanted" phenomenon.
>>
>> But it is definitely not going to be an upwards-compatible change.
>
> What will be different for a normal user? I.e. What basic lilypond
> notation will change?

You won't have to create an artifical chord in order to put string
numbers to notes or be able to tweak single notes.  Things like
fingerings and postevents applied to single notes will end up as
articulations rather than simultaneous events (which is what happens
when applied to chords).  It's conceivable that one will need to check
the music type system and provide a way to declare postevents that
should not end up as articulations on individual notes ever.

In short: I expect things to get a bit more streamlined at the input
side.

> And what advanced notation will break with that change?

I don't think notation will be affected, but the programming model
changes, and so music functions may need to get rewritten.  In most
cases, it should work to just replace their argument predicates with
more specific ones.  This can't be done automatically since some music
functions are intended to also work inside of chord notation and/or
apply tweaks, and consequently should _not_ get their arguments
converted to EventChord automatically.

-- 
David Kastrup



reply via email to

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