lilypond-user
[Top][All Lists]
Advanced

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

Re: music definition change in 2.9.9 or thereabouts?


From: Erik Sandberg
Subject: Re: music definition change in 2.9.9 or thereabouts?
Date: Tue, 20 Jun 2006 13:57:53 +0200
User-agent: KMail/1.9.1

On Tuesday 20 June 2006 12:59, Han-Wen Nienhuys wrote:
> Erik Sandberg schreef:
> > I'm not quite sure what the proper solution is. The attached patch solves
> > the problem by renaming EVENT_IDENTIFIER to ARTICULATION_IDENTIFIER. The
> > solution is easy and it works AFAICT, but it relies on music-classes,
> > whose fate is uncertain. I did consider the following solutions as well:
> > 1. Extend identifier-smob with type information (typically corresponding
> > to the return value of try_special_idetifiers). I think this will only
> > move the problem, because expressions like foo = #... must still be
> > assigned a type correctly.
> > 2. unify MUSIC_IDENTIFIER with EVENT_IDENTIFIER. This has one problem:
> > someone will try
> > foo = -.
> > { c2\foo d2 }
> > which (AFAICT) will put the dot above the d2
> > 3. Whenever a variable is assigned music, wrap it in a dummy
> > sequential_music. Unclean.
>
> Isn't it much easier to remove event from 'types for KeyChangeEvent (and
> rename to KeyChange ?). KeyChange remains an odd event; it should really
> be a property set for keySignature.

No. The underlying problem is that we now allow events that aren't wrapped in 
event-chords. So the following:

foo = c4

could make foo contain a NoteEvent directly. (I think it currently wraps the 
note in an EventChord, but I plan to change that). The problem is that 
variables that contain events directly, can currently only be used as 
articulations.

-- 
Erik




reply via email to

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