> Looking at the definition of the Music datatype ...
> we can see that phrase attributes can be nested, allowing
> one to write something like
> m = Phrase [Dyn (Crescendo 1.2)]
> ( c 5 wn [] :+: Phrase [Dyn (Diminuendo 1.2)]
> (e 5 wn qn []) )
> In practice I think it would not be desirable to allow such
> nestings when working with dynamics. How should the above
> music object be interpreted?
I think that a perfectly reasonable interpretation is possible; indeed
Haskore's "fancyPlayer" gives such an interpretation. The point is
that, although such a construction might not be common, or even
advisable, there is no easy way to disallow it, yet allow other more
common and meaningful nestings of dynamics.
The situation is not too dissimilar from Fran, where you can write
things like: withColor Red ( ... (withColor Yellow circle))
which might not be common, but are allowed and are well-defined.
> Should the inner (or outter) phrase attribute cancel the other?
> Should they be combined? How?
fancyPlayer combines them -- see the code in the tutorial -- but of
course you can define it anyway you like.
> The possibility of specifying the volume of each note allows
> someone to write a music object like these:
> m1 = Phrase [Dyn PPP] (g 5 qn [Volume 50])
> Wouldn't it be better to dissalow direct volume representation
> of each note and force the use of dynamics to obtain that controll?
Perhaps; I've thought about this a lot, and in fact I am reconsidering
the design of all of the articulation constructors (for other reasons
not mentioned here). On the other hand, the purpose of having the
NoteAttribute field is to handle things like the issue below.
> The volume of note may vary while it's played. The representation
> of music objects as implemented don't allow that using volume
> attributes for notes. ...
I don't know the best way to solve this, but I think that what you want
is a new NoteAttribute, whose interpretation generates the appropriate
Midi events. This needs to be thought through carefully, but would
require minimal change to the Music datatype, and more serious change to
the event structure. If you can come up with a good design for this I
would be interested in seeing it, or perhaps I'll take a look at it
later this summer.
Thanks for your comments,
-Paul
