Re: Notations in Scope

Hi Christina, Joe,

(Joe: I received your reply while replying to Christina. See below)

Christina said:
> Duration units are something that are up for grabs as far as I’m 
> concerned.
The fundamental, indivisible unit of duration (millisecond) is set for 
us by the current Web MIDI standard.

> It [..] becomes the responsibility of the AUTHORING_APP to either make 
> the durations match for matching symbols (all quarter notes at 1000ms 
> = 60 bpm tempo) or to not do so, as your app does.
Yes. There's no reason for an AUTHORING_APP to have to restrict its 
users to the tempo+tuplets time model. But it can if it wants to, of 
course.  It would be nice to have a commercial AUTHORING_APP that works 
more flexibly than that.

> The only reason to make the tempo an explicit temporal marker anywhere 
> would be so that the PARSING_APP can implement a metronome at the 
> right tempo…
Metronomic performances are actually very boring, and usually 
stylistically incorrect. Why not include a couple of performances that 
use timings by real performers? Mozart performed by Brendel or someone 
from a later generation... By the way, Mozart didn't use a metronome as 
far as I remember...
And what about older Music? Couperin or Lully synchronised with the 
durations from real performances would be a great help in learning how 
the notation works.
And New Music?

> To be clear, are we talking about switching to SVG as the next radical 
> rev of MusicXML [snip]?

MusicXML is an interchange format for exchanging information between 
CWMN AUTHORING_APPs. I'm assuming that it will continue to do that. 
Possibly a version could be made that would be the interchange format 
for the more flexible AUTHORING_APPs I mention above.

But that's on a different level from the INSTANCEs in the Global 
Architecture we are currently trying to define.
We currently have two candidates for INSTANCE frameworks: HTML and SVG.
At the Frankfurt face-to-face, Joe showed us how an HTML INSTANCE could 
be manipulated by CSS. My own starting point is SVG. My current feeling 
is that both HTML and SVG will have their uses in this area. One chooses 
the best approach for the task in hand.

I've just received Joe's reply to my previous posting:

Joe said:

> In my view (and I am aligned with the other co-chairs on this point): 
> No, we are definitely *not* talking about switching to SVG as an 
> overall framework for describing music -- particularly not for 
> describing CWMN, or mensural notation, or neumes, or other notational 
> languages with a well-defined symbolic vocabulary that transcends any 
> particular visual representation. I have described the reasons why I 
> think this is unworkable for software developers in the majority of 
> cases, and won't repeat them again here. Let me just say that for CWMN 
> scores, such a decision would make little more sense than using SVG as 
> the main architecture for plain text.
Exactly. Agreed.
> This does not mean that SVG has no role to play, though. For 
> notational schemes that cannot be encoded without reference to the 
> literal, visual contents of a score, SVG is potentially a good way to 
> encode such scores and annotate it with musical information. (I 
> personally do not favor directly including MIDI in the way that James 
> Ingram describes.)
Hmm. I'm curious to see how else the problem can be solved.
>
> A yes/no decision on SVG is not required right now. There is room to 
> accommodate this type of approach going forward. At the Frankfurt 
> meeting I spoke of Encoding Profiles 
> (https://www.w3.org/community/music-notation/wiki/Music_Notation_Use_Cases#Document_Profiles). 
> We can imagine a possible Encoding Profile which might state that the 
> musical content of a score is provided as SVG rather than 
> MusicXML-Next, with annotations similar in spirit to those proposed by 
> James. This Profile would be used by works which want to forego the 
> strictures of CWMN, etc. and are willing to give up the ability to be 
> interpreted by most notation software, other than that specifically 
> designed for this profile. You might think of the resulting profile as 
> an optional "graphical score module" within the overall framework, 
> whose apparoach is distinct from CWMN encodings. Both profiles might 
> well share many features like segmentation into movements, 
> bibliographic metadata, etc.
>
> I believe the work required to fully spec out a graphics-centric 
> approach to notation is considerable, and requires much more than 
> James's proposal so far. I don't think the CG should stop in its 
> tracks while solving all these problems. I would suggest that members 
> of the CG who are passionate about these cases develop their ideas 
> more or less independently for a while and then we look at how we 
> might fold the results into the overall spec.
Okay. I think I've said all I need to for the moment anyway.
Of course, if anyone wants to co-operate with me independently, they are 
very welcome. The result of a co-operation would probably have more 
weight when we get back together, than if its just me...

Back to active development! :-)

All the best,
James
  --
http://james-ingram-act-two.de
https://github.com/notator

Received on Friday, 22 April 2016 17:29:43 UTC