[Top][All Lists]

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

Re: Stream event structure

From: Erik Sandberg
Subject: Re: Stream event structure
Date: Thu, 6 Sep 2007 10:42:15 +0200
User-agent: KMail/1.9.6

On Thursday 06 September 2007, Ralph Little wrote:
> Hi,
> I'm trying to get to grips with how the new stream event system works by
> studying the code and following Erik's thesis.

Nice to hear!

> According to the thesis, the stream event contains a "context" field
> which contains the id of the outlet context for the event. I can't seem
> to find this in the event structure at all and I can't think of a good
> reason for it to be there anyway for the implementation as it stands.
> I'm playing with exporting streams and being able to identify a context
> id for the Voice would be really useful to me. Does anyone know how
> reproduce the listing that Erik has in his thesis including the outlet
> context id?
> Any help would be really cool.

There is no official external representation format for music streams; in the 
internal representation the context information is represented by appearance 
(if the event appears in voice V, then it belongs to voice V). A music stream 
dumper will typically consist of one listener per context, which exports the 
events to some textual format. This listener will typically associate each 
context object with some unique human-readable ID, and tag each heard event 
with this ID (when exporting you could e.g. use a context -> id hash table, 
and when importing a stream, use a hash table for id -> context).

Note that you will need to listen in each context for the creation of new 
child contexts, so that you recursively can add listeners to them as well.

FWIW, I've attached the code I used for import + export in my thesis (beware 
that they are written for an old lily version, and that they are not cleaned 
up, and that context ids were hardcoded in C++ code back then).

In that particular version of lily (2.6), I could override the translation 
procedure by setting the global function translator-proc; this is the entry 
point of my dumper/undumper. I don't know if this still is the way to go.

IIRC, I have written some similar code for the official implementation of 
streams, but it was lost when my laptop was stolen. If you're lucky, I might 
have published some code on lilypond-devel (but I don't remember).

Good luck!


Description: Text document

Description: Text document

reply via email to

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