> > This step is now finished, patch attached. You can notice some
> > additional stuff that has been added as well, which currently is
> > unused but will be used in future patches. You will notice that this
> > patch makes lily spit out lots of Junking Event messages, which are
> > harmless.
so I may apply the patch then?
> oh btw, there is one thing that strikes about the "unique" member/argument.
>
> It's type is rather arbitrarily set to int. Isn't it more sensible to
> make it an SCM value, and leave it up to the deliverer of the music
> stream to assign unique SCM values?
OK, unique in the sense of eq? seems sensible.
> Second question: the whole concept of unique seems a bit out of place to
> me: the number is essentially a marshalling device, making it possible
> to refer to a specific context inside a stream, saved as a file, but I
> don't see why it should be stored inside the Context struct. I think it
> would be more appropriate to generate the numbers via a
>
> map<Context*, int>
>
> member of the stream writer.
There's a problem with that: Context creation is triggered by stream
events, which tell which unique value to use for the new context. So
the unique value needs to be there before the context has been
created.
Hm.. this could be worked around by letting newly created context send
out confirmation stream events saying which context they belong to,
but that would mean that each context creation is represented by two
stream events, which must be consecutive. This adds some structure to
the music stream, which doesn't belong there imho.