- From: Glenn Linderman <v+smufl@g.nevcal.com>
- Date: Sun, 2 Apr 2017 19:27:16 -0700
- To: public-music-notation-contrib@w3.org
Given James' and Cecelio's discussion of internals, I'll go ahead and roughly describe my internals. Of course, it is not necessary that the XML map directly to anyone's internals, it is expected that everyone's internals will be different, for different goals and purposes. On the other hand, if there be no or few known program's internals use measure as a container, why should MNX? It would only add complication to programs that don't. As you might expect from my lead-in paragraph, my program (not public, but has been used to create over 30 books of music and lyrics) does not use measure as a container. Neither does it use any graphical structure as containers, such as James describes regarding pages, systems, lines, and movements. Rather, pages and lines are scattered about where needed in the temporal order, in a manner similar to, and sometimes independent of, the locations of barlines (as James describes, sometimes it might be that a measure cannot fit on a line, but more often the case is that in fitting music to book form, that certain measures are broken to assist in the layout). My internal data structure is time based, rather than graphics based... all items across a system are grouped if they "sound" concurrently (of course, rests don't exactly sound). I call these items "syllables", derived from the "hunk of lyrics" that is associated with some of them, but it probably isn't the best name... I just never took time to discover or create a better term (suggestion welcome). Into this temporally linear data structure of notes, rests, barlines, and performance directives, then, additional "syllables" are inserted for layout purposes (which I call layout syllables), and they contain sufficient information regarding the page layout, the need for clefs and signatures, system connectors, and margins in both dimensions. There is generally at least one layout syllable per line of graphical music. I don't claim this is the best structure for all purposes, but it has been generally satisfactory for my use for the last 34 years. Initially a binary structure, I have converted it to compressed JSON in more recent times, finding paired XML keywords generally more distracting than helpful, but as an interchange format XML probably has more mature tools for schema description and validation (although such tools could be written for JSON, and maybe have been, unknown to me). Note that performance directives that change the sequence of play (repeats, D.S., D.C., Coda, etc.) prevent the sequence from being 100% temporally ordered. Playback simply follows the directives, accumulating key points (begin movement, begin repeat, Segno, Coda) which may be return points as they are discovered, and treating the others (end repeats, D.S., etc.) as a go to... just like a human player would, given the printed notation. On 4/2/2017 10:29 AM, James Ingram wrote: > I'd like to add a couple of points: > > 1. My measure-free solution for SVG instantiations is not an argument > for leaving measures out of MNX. > My authoring software (which would be an MNX /client/) uses measures > internally, so that its easy to concatenate them for particular system > layouts. It might be better to make it easy for such apps to construct > an internal structure consisting of a flat list of measures, so that > they can then give their users the choice of where the system breaks > should go. Such a container hierarchy might be: > page-->system-->measure-->staff-->voice-->event. > (I still think that MNX containers should be /graphically consistent/ > containers.) > It would be possible, using this hierarchy, to write a valid MNX file > containing a single measure that would not fit on any available page. > (MNX has no idea how big the page is going to be.) In such a case, the > MNX client app has to be able to break the measure anywhere its user > thinks would be a good idea. That's just a problem for the app, its not > the MNX format's problem. The app can then export SVG (maybe in a format > like the one I outlined) or a new MNX file. The MNX for this "one > measure score" would have one measure per system, and all the final > barlines except the last would be missing (or invisible...). > > 2. Note that this is all has /only/ to do with the graphics. (The way > the score /looks/.) Any temporal information contained by an event > symbol just moves with its container, and can be concatenated across a > particular voice to describe a continuous stream. On the graphic level, > annotations such as time-signatures, tempo markings, tuplet brackets, > augmentation dots, staccato dots etc can be added ad lib., but a > complete description of what they all /mean/ will still just be stored > in the event symbols. > > 3. Please excuse my frequent use of "bar" to mean "measure". I actually > prefer the UK-English terms, since bars are just objects in space (that > are aids to legibility). Nothing is actually being "measured". Similarly > for the duration class names: a crotchet was originally a hook-shaped > object -- its not a quarter of anything... :-) > > All the best, > James > > > Am 02.04.2017 um 16:04 schrieb cecilio: >> Glen has raised an interesting alternative: allowing barlines to be >> notated, rather than thinking of measures as containers. >> >> In fact, that is exactly the solution I use in my software >> LenMus/Lomse. It allows a uniform treatment of single metric scores, >> measure-free scores and, not yet mentioned, *multi-metric music*. But >> I'm not defending this solution. I would like just to raise the need >> for careful thinking about the a clean MNX solution not relaying on >> 'tricks' such as: >> >> - non-controlling barlines for CWMN multi-metrics music. >> - hidden measures / barlines for CWNM measure-free music. >> >> Multi-metric music is also related to the issue of notating barlines >> at <system> level or at <part> level, raised in another post. >> >> In my experience it is, perhaps, simpler to deal with a solution based >> on measure containers (with an special measure container for >> measure-free scores). But to deal with multi-metrics and measure-free >> scores I have cosen a solution based on notating barlines as staff >> objects and not using measure containers gives more flexibility and >> is, IMO, more 'natural'. Anyway, I'm not defending this solution. I >> just tried to take into consideration the need for a clean solution in >> MNX for multi-metric and measure-free scores. >> >> Cecilio >> >> On Sun, Apr 2, 2017 at 1:31 PM, James Ingram <j.ingram@netcologne.de >> <mailto:j.ingram@netcologne.de>> wrote: >> >> Hi Dennis, Glenn, all, >> >> Welcome Dennis! This is getting very interesting! :-) >> >> My own version of the container hierarchy was created from first >> principles, and does exactly as Glenn suggests: It treats barlines >> simply as notated lines. They are graphical aids to /legibility/ >> rather than being musically structural. They just chunk areas of >> the page to make reading easier. >> >> For discussion purposes, here's my reasoning: >> >> My outermost container is the *page* (an <svg> element in an SVG >> document). Printable pages have finite width and height. So do >> computer screens. It is possible to scroll pages on a screen, >> either horizontally or vertically, but scrolling very wide pages >> horizontally is strangely disorienting. System breaks are >> reassuring, and aid to legibility. So my *page* containers always >> have a /width/ that should fit on a computer screen. The authoring >> software can decide which screen width the score is written for. >> >> (From here on, I'm simplifying a bit, for the sake of getting the >> principles across.) >> >> The next container level down (inside *page*) is the *system*. >> Systems stack vertically on the page with margins to the left and >> right. System containers contain *staff* containers and >> *staffConnector*s. >> >> A *staff* has the width of the system. A *staffConnector* is a >> vertical line between two staff containers. Staff containers stack >> vertically inside their system, and contain *voice* containers. >> >> A *voice* container has the width of its containing staff, and >> contains a sequence of objects that include *clefs*, *barlines* >> and *event symbols*. (This arrangement owes a lot to capella's >> CapXML "noteObject"s. ) >> My authoring software only draws *barline*s into the first voice >> in a staff. It might be better to draw barlines a level higher, in >> the staff container. >> An advantage of differentiating between barlines and >> staffConnectors is that they can be styled differently. >> Stockhausen often wanted to group instrument types differently in >> this way. For example: In a large score, the staffConnectors >> between woodwind staves can be the same thickness as the barlines, >> while the staffConnectors between the woodwinds and the brass can >> be thinner. >> >> XML was invented to be both machine-readable and human-readable. >> Its a big help, when debugging, to be able to collapse the >> containers in an XML editor in order to find a particular object. >> So I think its a good idea to make the XML containers contain >> everything that belongs graphically inside them. I'd therefore >> prefer it if <part> elements in MNX ยง5.1.2 were contained in the >> <system> element. (If I've understood the example correctly.) >> >> Note that my version of the container hierarchy is based strictly >> on /graphical containment/. The old problem of moving notes from >> bar to bar is still there, but it has become a problem of moving >> notes from system to system. >> Note also that the /temporal definition/ of a tied symbol goes in >> the first event symbol. All the rest (tie, tied symbols) is just >> graphics. >> >> All the best, hope that helps, >> James >> >> >> >> Am 02.04.2017 um 01:20 schrieb Glenn Linderman: >>> Dennis raises a valid point, though... does a measure have to be >>> a container at all? A measure extends from one bar to the next, >>> but the sequence of notes and bar lines can be thought of as a >>> exactly that, a sequence, rather than a containment concept. As >>> has already been mentioned, sounded notes can escape the >>> containment by being tied across bar lines. Further, shifting >>> things from one measure to the next may be far easier by moving >>> the bar lines in the sequence rather than moving notes from one >>> container to another. So there are some merit to simply allowing >>> bar lines to be notated, rather than thinking of measures as >>> containers (either in the logical or XML sense of containment). >>> >>> On 4/1/2017 12:05 PM, Joe Berkovitz wrote: >>>> Hi Dennis, >>>> >>>> Speaking as a composer, "one big measure" is still some sort of >>>> container and >>>> therefore incorrect. I have not understood in these >>>> discussions and in >>>> existing software why the measure must be the basic >>>> consideration >>>> in encoding >>>> information. >>>> >>>> >>>> If we used a <measure> element in this way, it would be just a >>>> "container of convenience" to hold a series of events and would not >>>> imply a notated measure. We'd want to figure out a way to make >>>> sure that >>>> this understanding was part of the encoding. I wish I had not >>>> used the >>>> term, "one big measure": I simply meant, one big container. It >>>> may make >>>> sense to name the element differently in this case -- that, too, >>>> is up >>>> for discussion. >>>> >>>> Truly, there's no claim here that measures are a basic >>>> consideration in >>>> encoding music. Where measures exist and the composer notated them, >>>> though, I think it's reasonable to include them in the encoding >>>> as part >>>> of what the composer chose to express. Where the composer didn't >>>> do so, >>>> then the encoding can say that too. >>>> >>>> With respect to the other generalities that you talked about, I >>>> think >>>> we're envisioning that MNX will *also* include a culturally neutral >>>> encoding approach based entirely on graphics and time, and that >>>> this >>>> will provide an escape valve for the many notation systems that >>>> don't >>>> fit the 1600-1900 model. The emphasis you see in the CG's work >>>> right >>>> now, in no way excludes our taking up a more general approach as >>>> our >>>> resources and time allow. >>>> >>>> I don't feel there is a "tendency to create a [traditional Western] >>>> system". It's just that there is a large proportion of CG members >>>> writing applications that work within this system. Our present >>>> priorities merely reflect the makeup of the group. And they are >>>> just >>>> priorities, not decisions about what notation is or is not. I look >>>> forward to having the time to devote to thinking through the more >>>> general graphical/temporal approach as well. >>>> >>>> Best, >>>> ...Joe >>>> >>>> >>>> Music proceeds. If a measure-based composition is encoded, then >>>> apply the >>>> markers that determine these aspects (barlines, time >>>> signatures, etc.). >>>> Dumping the measure, it seems to me, relieves all the >>>> struggles with >>>> time >>>> signatures (such as 4/3 or 3/7) and, of course, notation >>>> systems old >>>> and new >>>> that don't use measure-like divisions at all. If a >>>> time-based system is >>>> encoded, then the container, if you need one, can be the >>>> second. If an >>>> instrument-exchange based system is encoded, the container >>>> (again, >>>> if you need >>>> one) is the exchange division. If the answer is 'none of the >>>> above', >>>> then the >>>> encoding system should be required to respect the music -- >>>> first. >>>> >>>> With no measure container, for example, having a continuous >>>> staff >>>> that changes >>>> as needed (containers, no containers, switch to time-based, >>>> directional, all >>>> on the fly) also frees the encoded notation from straight, >>>> horizontal lines >>>> (meaning no trouble encoding Wolff or Stockhausen). >>>> >>>> I'm not a coder anymore, but I see a tendency to create a >>>> system that is >>>> driven by Western music 1600-1900. Don't we already have >>>> plenty of >>>> systems >>>> that do that? It seems to me that any new system that >>>> depends on that is >>>> either mostly redundant or, with respect to the continuing >>>> development of >>>> music, destined to fail. >>>> >>>> So can the measure 'container' please be scrapped? >>>> >>>> Dennis >>>> >>>> >>>> >>>> >>> >>> >>> >> >> -- >> https://github.com/notator >> http://james-ingram-act-two.de >> >> > > -- > https://github.com/notator > http://james-ingram-act-two.de
Received on Monday, 3 April 2017 02:33:02 UTC