- From: Glenn Linderman <v+smufl@g.nevcal.com>
- Date: Mon, 3 Apr 2017 12:47:58 -0700
- To: public-music-notation-contrib@w3.org
On 4/3/2017 4:00 AM, James Ingram wrote: > Hi Glenn, > > This discussion of application internals may look a bit private, but I > think this CG needs need to explore the needs of /all/ its app > developers, not just the big commercial ones. > I'm currently leaning towards the inclusion of <measure> in MNX (see below). > > Glenn said: >> [...] if [...] 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. > I don't think the complication would actually be very great. Its just a > case of having another level of looping in the parsing function. On the > other hand, including <measure> might considerably simplify the parsing > for some applications. Imagine trying to parse my measure-free SVG > format to create a list of <measure> objects! I think we'll just have to > wait and see how the commercial vendors want to do this. Sure. I don't fully understand your SVG format, so I can't really imagine that, but if something is truly measure-free, bundling it into measures is likely to result in a hodge-podge similar to various of today's notation programs attempting to parse recorded MIDI files (which often don't have a time signature or key signature that truly corresponds to the recorded music, not to mention not having fermatas or pauses, which can significantly confuse the attempts of the notation programs to determine what a measure is)! And yes, if measure is a container, then for music that has measures, it is just another level of looping to flatten it out into my internal structures. But for music that doesn't have measures, I would also have to handle an extra case of a different technique for handling music with measures, and music without measures. None of these options is insurmountable; but every time you avoid a special case, you avoid having to document and implement those special cases. > > Glenn again: >> 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 [...]. > I'm not sure that I understand you correctly. Is the following correct?: > 1. The top level of your internal data structure is a list of *system* > objects. > 2. Each *system* contains a list of *syllable* objects. > 3. Each *syllable* > a) occurs at a particular time and > b) contains a list of concurrent *item*s. > Presumably, the *syllable* happens at a time relative to the *system*, > and the *system* happens at a time relative to the performance. The > duration of a *system* is the duration of its list of *syllable* > objects. So each *syllable* has a duration (including the last one on > the list). > At this point, your *syllable* is sounding rather like what I call a > *<score:midi>* object in > https://github.com/notator/Moritz/issues/3 > > But then you say that a *syllable* can contain a "hunk of lyrics". Is > that a recording (something temporal), or do you mean a string of text? That was somewhat ambiguous, indeed! Thanks for trying to puzzle it out. The "hunk of lyrics" is a (literal) syllable of a word that might be sung with the melody note if there is one in the particular "syllable" of (my data structure) music (and that text is represented in UTF-8 text these days; prior to Unicode, it was an extended ASCII). One-syllable words are complete, multi-syllable words are generally divided into pieces, with metadata that indicates what types of separation, spacing, or juxtaposition are valid for assembling a printed score, depending on available spacing during score layout. > If you mean a string of text, then I think your *syllable* has to be > extended to contain a graphics component. In other words, it becomes > equivalent to an MNX <event> symbol (if such <event>s contain both > graphics and temporal info). I'm not sure my data structures (at present) make a clean separation between graphics and performance: the program is primarily concerned with creating the graphical scores, but sufficient playback capabilities are included to allow "proof-reading" of the score by ear, which is far more effective than only looking at displayed or printed results. > Is that correct? Did I get something wrong? If I'm right, then you > should have no trouble reading MNX <event> symbols into your internal > data structure. I don't foresee any major difficulties in reading MNX due to the existence or non-existence of <measure> as a container. Nor, if my program used measures as a container internally, would I foresee any major difficulties in reading MNX due to the existence or non-existence of <measure> as a container. Really, the thought processes and points I was trying to make are that: 1) a program exists that supports display of measures without the requirement that they be a structural container. 2) discussion has indicated that music exists that does not have measures (I'm not particularly familiar with that type of music, but no matter; my program would not suffer internally from such music). 3) Any requirement that the structural form of measures as containers then requires (because of point 2) that some special case exist (be created, documented, implemented) to handle music not having measures 4) Special cases complicate things. 5) There is proof (because of point 1) that measures can be handled without implementing them as containers. 6) Hence, it is not necessary for a standard to promulgate measures as containers, and cumber itself with special cases for music without measures, simply by creating the standard without using measures as containers. Now point 6 has reached a conclusion different than you have. I have no idea whether or not commercial programs use measures as containers in their internal data structures, nor if they do, whether or not that is deeply embedded into the logic of their internals, nor, if it is embedded, if it benefits them highly, or causes them problems with internal manipulations for operations that need to shift where measure bars are placed. So far, no one in this discussion has outlined, demonstrated, or described how using measures as containers benefits musical semantics. >> 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. > The arrow of time is notoriously inexorable! :-) > Apropos repeats, D.S., D.C Coda etc.: In my proposal, <event> symbols > have a duration that is independent of their absolute temporal position. > Global time is just the result of adding such durations. If <event>s are > repeated later in a performance, their durations just get added again. > Since I'm allowing particular <event> symbols to contain multiple > temporal interpretations, its quite conceivable that a repeat of the > graphics would use a different interpretation. Real performers never > play the same thing twice... > > All the best, > James > > > > Am 03.04.2017 um 04:27 schrieb Glenn Linderman: >> 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >
Received on Monday, 3 April 2017 19:48:46 UTC