Re: In C (Terry Riley)

Hi James,

Please leave off trying to make the CWMN aspect of MNX into a generalized
representation for arbitrary music notation. It is not designed to work to
do that. I do not want to have more discussions about how to use the
current CWMN proposal to cover pieces that lie well outside of its range.

Let me say again: a different strand of this group's work is going to
address the larger, broader range of music notation, and this should
include pieces like Riley's works, which which I'm familiar. It should also
include pieces *much further* from CWMN.

I suggest we discuss this tomorrow in person and not belabor these points
on the list until then.

Best,

.            .       .    .  . ...Joe

Joe Berkovitz
Founder
Noteflight LLC

49R Day Street
Somerville MA 02144
USA

"Bring music to life"
www.noteflight.com

On Thu, Apr 6, 2017 at 11:48 AM, James Ingram <j.ingram@netcologne.de>
wrote:

> Hi Dennis, all,
>
> This is a new thread, but in reply to Dennis' contribution quoted (with
> link) below.
>
> Thanks, Dennis for pointing out this very interesting case and pushing the
> debate along!
>
> *In C* is a classic mobile score. We are talking about music as Art here.
> Listening and performing responsibly is what this piece is all about.
> Making a version of *In C* for a particular ensemble, with all the
> repeats written out, would change the relation of the players to their
> performance. They would stop listening to each other and start
> concentrating on not getting lost. That's quite different from the
> situation in Stockhausen's *Momente* or *Refrain*.
>
> Nevertheless, I think it should be possible to save *In C* in MNX.
>
> [begin aside]
> Issue: Can MNX allow more than one container hierarchy?
> It would often be more efficient to be able to leave levels out. For
> example, the following could be possible:
> <system> - <measure> - <staff> - <voice> - <event>
> or
> <system> - <measure> - <staff> - <event>
> or
> <system> - <measure> - <event>
> or
> <system> - <event>
> [end aside]
>
> The 53 *In C* melodic patterns could be saved in 53 <measure> containers
> in a single <system> having the following container hierarchy:
> <system> - <measure> - <event>
> Each <event> would contain a single duration symbol graphic (chord or
> rest). The symbols' temporal data could be left empty (to be managed by the
> client application, which would be programmed in accordance with the
> performance instructions). The two pages of performance instructions would
> go in a text <annotation> somewhere.
>
> It would then be *possible* to write an application that would
> instantiate and play a score on the fly.
> Imagine a dialog setting up the instruments before starting to play, then
> controls on each instrument allowing the user to tell them to stop or move
> on, introduce slight imperfections of duration in individual parts, control
> their dynamic etc. It would also be possible to record such an
> interactively created score, reformat it and play it back.
>
> However: Such a procedure would lose the musicality of the original, live
> performance with an ensemble of real players. At least, it would transfer
> the communal responsibility for the performance to a single "conductor". It
> just wouldn't be the same piece. We are talking about a complex Artwork
> here.
>
> Note that the borderline between programming (applications) and composing
> (music) is getting blurred here.
>
> I'm confused by the idea of temporal information having a role in notation at
> all.
>
> Its exactly that (19th and 20th century) confusion that I'm trying to sort
> out.
> Temporal information is not spatial, so there is actually no necessary
> connection between the temporal information and the notation at all. Any
> connection there might be is in the intention of the person who set the
> relation up. Its often done with particular expectations in mind, but there
> are no restrictions anywhere. Imagine the case of transposing instruments,
> or organ stops etc.
>
> A fond memory of student days is that I once broke a piano string while
> playing the drone in *In C* (ca 1970?). I must have hit the string just
> when it was going in the wrong direction... :-)
> Hope that helps,
> James
>
> http://lists.w3.org/Archives/Public/public-music-notation-
> contrib/2017Apr/0059.html
> Am 05.04.2017 um 15:20 schrieb Dennis Bathory-Kitsz:
>
> On Wed, April 5, 2017 8:35 am, James Ingram wrote:
>
> Detailed Temporal Information (relevant to Performance Practice):
> Thus far, the only temporal information I've mentioned relates to the
> order in which <system>s or <event>s are played. That's just a simple
> before-after relationship.
>
> I don't think you mention parallel but unsynchronized elements. The easiest
> example is "In C" -- the score is graphically simple, but the performance is
> not. Is this kind of score a special case? Your 'arrow of time' always moves
> forward, but the events loop at different times. Is this a case where the
> graphical score must be unhooked from a performance because each performance
> is very different?
>
> I'm confused by the idea of temporal information having a role in notation at
> all.
>
> Please ignore this if my question misperceives the issues.
>
> Dennis
>
>
>
>
>
>
> --
> https://github.com/notator
> http://james-ingram-act-two.de
>