Re: Call for ideas: Music Stream applications.

[Erik Sandberg]

On Sunday 28 August 2005 15.53, Trevor Baca wrote:
> On 8/28/05, Erik Sandberg <address@hidden> wrote:
>
> I have not yet taken advantage of \partcombine and related functions,
> but it seems apparent that a reimplementation using music streams
> would be *much* simpler than the current implementation. After a
> couple of releases, such a reimplementation would presumably be more
> stable, which is a direct user benefit. I ran into a minor bug with
> \setAssociatedVoice the other day when engraving a song with
> multivoice alternatives in the vocal part; it seems clear to me that
> \setAssociatedVoice would be another good candidate for a more stable,
> powerful reimplementation under music streams (just as the thesis
> analyzes for \lyricsto).
(I think that analysis is obsolete btw)

> Other applications for music streams occur to me but I'd like to ask
> two questions that I've been mulling over before I hazard more
> guesses:
>
> 1. will music streams represent all the "default" items the Lily
> inserts *after* parsing an input .ly file, such as clefs,
> timesignatures and the like?

It represents the same information that a music expression currently does.

AFAICR, time sigs and clefs are handled internally by setting properties, that 
an engraver later uses to produce the symbols. Music streams will contain 
SetProperty events that set those properties accordingly, but it will contain 
no explicit clefs/time sigs. 

> 2. the example music stream included here shows (if I'm reading
> correctly) "what is connected to what" primarily by stream events
> sharing the same music moment (in vertical direction) or by sharing
> the same context (in the horizontal direction); ie, a NoteEvent and a
> LyricEvent connect to each other (in the vertical direction) by virtue
> of sharing the same music moment while two notes in the same voice
> connected to each other by sharing the same context. First, are these
> correct assumptions? 

Yes.

> Second, will music streams represent information 
> about "what is connected to what" in ways in addition to music voice-
> and moment-concurrency?

No. 

I've been thinking about supporting 'comment' events, which just would be a 
kind of arbitrary hints, ignored by the typesetter.

This could be useful for converters (e.g. music-stream => MusicXML), where 
each lyric _must_ be connected to a note. It could also be useful for 
music-stream=>ly conversion, e.g. to hint that a lyrics context can be 
represented with lyricsto.

> Examples might include: tempo indications 
> connecting (left aligning, say) with time signatures (not possible
> explicitly under current Lily implementation, though Han-Wen's willing
> to take on the feautre under sponsorship); 
That decision belongs to a later step in processing, I think. My guess would 
be that alignment tweaking like that would be done through that spanner's 
grob properties.

In any case, what can be represented in a music stream, should always be 
representable in .ly, and vice versa, so new alignment must be representable 
in .ly as well. Music streams doesn't (and can't) change the model lily uses 
to describe music.

> voices wandering over two 
> or three different staves as frequently happens in piano music (which
> already is possible under the current Lily implementation using
> \changes); 
This is represented by letting events belong to a Voice, and inserting 
ChangeStaff stream-events that makes that voice move across staves.

> To this list, of course, you
> could add the point you brought up on the mailing list the other day
> about multistaff chords.

Also not particularly related to music-streams, afaics. The problem with those 
chords, is that one voice belongs to two staffs at once, this breaks the tree 
hierarchy.

-- 
Erik