lilypond-devel
[Top][All Lists]
Advanced

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

Re: Updated stream/parser todo


From: Erik Sandberg
Subject: Re: Updated stream/parser todo
Date: Mon, 19 Jun 2006 12:12:05 +0200
User-agent: KMail/1.9.1

On Friday 16 June 2006 14:46, Han-Wen Nienhuys wrote:
> Erik Sandberg schreef:
> > On 6/16/06, Han-Wen Nienhuys <address@hidden> wrote:
> >> Erik Sandberg schreef:
> >> > 3. Make translators listen to stream events, and make MusicEvent
> >>
> >> stream-events
> >>
> >> > contain properties directly. Furthermore, represent all events as
> >>
> >> stream
> >>
> >> > events rather than music from the beginning. I think this will take
> >>
> >> some
> >>
> >> > time.
> >>
> >> Question: how will you deal with all the Scheme user code that this
> >> change will break?  Every music function nowadays uses ly:music-property
> >> on XxxxEvents.
> >
> > We could make ly:music-property accept stream events as parameters,
> > but give warnings.
> >
> > Hm.. it's a bit problematic that certain events (NoteEvent) will be
> > split up into one Music and one Stream-event. Perhaps we can construct
> > a hack that handles invalid music-property settings by checking for a
> > Stream_event child and try to set it there instead, along with a big
> > fat warning.
>
> This doesn't sound like a very clean solution, which is troublesome
> given that the original (IIRC) motivation was to clean things up.

Not necessarily; the unclean workarounds are temporary and isolated, and will 
only last until we decide to drop backward compatibility.

> Isn't this something we'd better postpone to 3.0 ?

Possibly.

In any case, I think I've found a decent alternative: We can let all music 
events stay more-or-less as they are, but junk event-chords (use 
simultaneous-music instead), and make music-events use their own iterators. 
These iterators will perform any necessary duration-callbacks etc, and then 
create and send a stream event around each music-event's mutable property 
alist.

Regardless of what we decide as the 'final' music expression format, this 
feels like a good intermediate step.

BTW: May I change Sequential_iterator::get_music_list to return something like
scm_call_1 (get_music ()->get_property ("child-list-callback"), get_music 
()->self_scm ());
?

This would make it possible to soft-code e.g. percent-repeat-iterator.

-- 
Erik




reply via email to

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