altMNX: An alternative to the CWMNX+GMNX proposal #25
Comments
joeberkovitz
changed the title
|
I've retitled this to make it clearer what the issue really is here. The example attached incorporates a number of other ideas and those should be moved to other separate issues and more clearly explained. I would like to point out that I've spoken with the chair of the SVG Working Group @svgeesus (Chris Lilley), who's said that either approach (SVG-inside-GMNX or GMNX-inside-SVG) is valid and neither one amounts to reinventing the wheel. So it's really just a question of which one works better for us. I'll present some arguments later on about why I think it makes sense to have SVG inside GMNX, but for now I'll let this conversation unfold further. One other point to defuse here: even if we put SVG inside GMNX, that doesn't mean we can't break the SVG out into a separate file of its own, and have GMNX incorporate it by linking to it. That is also an attractive option. |
|
@joeberkovitz Thanks for the constructive tone above. :-) We can open and clarify subsidiary issues when we have agreement on the main issue here: What role(s) does SVG play in a GMNX file. Its an interesting suggestion, that the SVG could be broken out into a separate file of its own. Perhaps you could say some more about that? What uses do you envision for the standalone SVG file? What uses do you envision for the GMNX file? SVG files can be embedded in HTML, so what advantages would GMNX have over HTML? I'm trying to ask serious, not polemical questions here. |
|
If the SVG piece of GMNX as proposed is broken out into a separate file, then we make it easier for SVG-only applications to just use that document alone as pure graphics, which is one of the points raised by @notator. I don't see any change at all in the content of the SVG being needed to make this happen, relative to what's been proposed so far. The SVG would still contain IDs and optional references back to a semantic document (e.g. a CWMNX file). GMNX would still contain performance information like timed events, or time ranges in a separate audio file, and would tie these back to regions and event symbols in the SVG. So at the end of the day, the role that SVG plays in a GMNX file is the same after the file is broken out. Namely...
|
|
I've broken out issue #31 so that the issue of GMNX graphics being directly consumable by SVG-aware applications does not get confused with this issue, which is about whether GMNX performance data is directly embedded within SVG elements. |
|
At this point I'll try to describe this issue more clearly, by contrasting the two proposed ways (embedding and cross-referencing) of encoding performance and graphics information, and then discussing pros and cons. Because both approaches are capable of representing exactly the same information, both of my examples are going to use exactly the same element names and the same terms to describe them (the ones that are used in the present GMNX proposal). The aim is to minimize the confusion from bundling many other minor changes into this issue. ScenarioThe example will be a very short CWMN passage: a two-note measure that lies within a repeated section of the score, and is thus played twice. Performance directions in the score prescribe that the first repeat is f, and the second repeat pp. Furthermore, there are two different performances to be encoded in the GMNX representation: an audio performance in an MP4 file, and a timed-event description in terms of pitch/onset/duration/dynamics. Omitted for clarity are...
Finally, to eliminate the issue of SVG being usable as a standalone file or not, we'll assume that in both cases the SVG is encoded as a separate document (although it obviously looks different in each case). Cross-referencing approachIn this scheme, a GMNX document represents each performance as a single element with descendants occuring in time order. The events and regions within each performance are cross-referenced to the corresponding elements in an SVG file, using their IDs. score.gmnx: <graphics src="score.svg"/>
<performance>
<performance-name>Event sequence</performance-name>
<performance-events>
<track>
<sequence>
...events prior to first repeat
<event graphic="#note1" start="5" duration="0.25">
<note pitch="E4" dynamics="100"/>
</event>
<event graphic="#note2" start="5.25" duration="0.25">
<note pitch="F4" dynamics="100"/>
</event>
...events prior to second repeat
<event graphic="#note1" start="10" duration="0.25">
<note pitch="E4" dynamics="20"/>
</event>
<event graphic="#note2" start="10.25" duration="0.25">
<note pitch="F4" dynamics="20"/>
</event>
...remainder of score
</sequence>
</track>
</performance-events>
</performance>
<performance>
<performance-name>Audio recording</performance-name>
<performance-media>
<media-file src="score.mp4"/>
</performance-media>
<performance-regions>
...audio regions prior to first repeat
<region graphic="#note1" start="5.01" duration="0.27"/>
<region graphic="#note2" start="5.28" duration="0.24"/>
...audio regions prior to second repeat
<region graphic="#note1" start="9.98" duration="0.26"/>
<region graphic="#note2" start="10.24" duration="0.24"/>
...remainder of score
</performance-regions>
</performance>score.svg: <svg>
...other parts of graphical score
<g id="note1">
...graphics for the first note
</g>
<g id="note2">
...graphics for the second note
</g>
</svg>Embedding approachIn this scheme, a GMNX document is an SVG document. All events and regions in each performance are embedded within the graphic that they refer to. Structurally, this is along the same lines as @notator's example at the beginning of the issue, except that it doesn't reinvent the way that performances are described or introduce special uses of score.svg: <svg>
...preamble providing overall performance data
<mnx:performance id="eventPerf">
<mnx:performance-name>Event sequence</mnx:performance-name>
</mnx:performance>
<mnx:performance id="audioPerf">
<mnx:performance-name>Audio recording</mnx:performance-name>
<mnx:performance-media>
<mnx:media-file src="score.mp4"/>
</mnx:performance-media>
</mnx:performance>
...other parts of graphical score...
<g id="note1">
<mnx:event performance-ref="eventPerf" start="5" duration="0.25">
<mnx:note pitch="E4" dynamics="100"/>
</mnx:event>
<mnx:event performance-ref="eventPerf" start="10" duration="0.25">
<mnx:note pitch="E4" dynamics="100"/>
</mnx:event>
<mnx:region performance-ref="audioPerf" start="5.01" duration="0.27"/>
<mnx:region performance-ref="audioPerf" start="9.98" duration="0.26"/>
...graphics for the first note
</g>
<g id="note2">
<mnx:event performance-ref="eventPerf" start="5.25" duration="0.25">
<mnx:note pitch="F4" dynamics="100"/>
</mnx:event>
<mnx:event performance-ref="eventPerf" start="10.25" duration="0.25">
<mnx:note pitch="F4" dynamics="100"/>
</mnx:event>
<mnx:region performance-ref="audioPerf" start="5.28" duration="0.24"/>
<mnx:region performance-ref="audioPerf" start="10.24" duration="0.24"/>
...graphics for the second note
</g>
</svg>Discussion
|
|
@joeberkovitz Audio files Repeats and Performances In the introduction to Embedding approach, you say:
Could you say why you object to the way I have described performance information? If you mean my use of MIDI to describe events, I must ask how you propose to describe ornamented chords and continuous controllers. (This may have to be done in different ways in CWMNX and GMNX.) Argument 1 in favour of the embedded approach: In issue #28 I said:
I think the standard use of SVG class attributes is a must, owing to their relation to CSS, and that their use makes a separate file containing the class information redundant. I've pointed out before, that CWMNX element names generally correspond to class names in the instantiated SVG. (e.g. a CWMNX This is true, not only for event symbols but also for containers. Container hierarchies are part of my proposed score typing scheme (see the comment in the skeleton code above). Notice that you have not included the container hierarchy in your Embedded example, and then consider what happens if the score is not CWMNX but simple text having the container hierarchy Argument 2 in favour of the embedded approach: An application that starts without an imported CWMNX file, or creates non-CWMN scores, would first have to create a file containing the abstract element structure (a CWMNX file or some equivalent non-CWMN file) and then write an SVG using ids to reference the abstract elements. It would be much simpler just to declare the score type and use element classes directly in the SVG. Your discussion points:
I don't think that's really a problem. On the web, Javascript is extremely fast, and desktop applications would if anything be faster. The score can be read before any performance begins. Some very large scores might require a multiprocessing approach (reading and performing at the same time), but I don't think that's fundamentally unsolvable by today's software.
Applications that export performable SVG files (GMNX) could very easily also export simple SVG files that don't include the performance data. These are just two closely related export options.
Not sure that I understand that. It sounds rather like the approach I took to linking to Audio files. But If the file fails to closely associate performance data with graphics data, then it can't really be a candidate for what we are looking for. Other discussion points: |
Actually, in addition to class selectors, CSS uses IDs, types, and attributes as well as hierarchy-dependent selectors (descendants, direct children, siblings, adjacent siblings). For your reference: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Selectors. As for the general subject of this thread, I support cross-referencing rather than embedding. @notator is making many specific arguments about the advantages that he sees in embedding, but from a developer's perspective keeping the different data types separate makes them much easier to work with. There is an argument to be made that embedding might be the more musically-intuitive model, but let's put an end to the idea that there would be a technical advantage in that approach. |
|
I'd just like to say that I have now improved my Assistant Performer's documentation by providing mp4 videos of the app in action. These can be viewed without having to install any browser plug-ins.
Two other things I should say while I'm here:
|
.svg){kind=link}
notator
changed the title
|
I've been asked to continue all my closed issues here. #36 first: If there is a standard format for cwmnGMNX scores, then the following scenario becomes possible: Further to #26 and #37: New Issue: All GMNX dialects should have a standardized, non-functional "annotations" or "user" level for comments and other non-standard reading aids (user notes, spectacles etc.). Issue: CWMNX vs. cwmnGMNX? |
notator
changed the title
|
I've changed the title because the new MNX Draft Specification says that GMNX is
I was using the term GMNX above to express the fact that this proposal is extensible to non-CWMN notations. |
notator
changed the title
notator
changed the title
Issue: cursorsThe treatment of cursors described above (on 2nd May 2017), could be much improved by describing them with explicit JSON strings having a structure similar to the one below. The object hierarchy
Each position definition contains
Sub-issues
This is an issue. Constructive suggestions for improvements, alternatives etc. would be very welcome. [1] The oggPngPlayer was originally written to duplicate the behaviour of @joeberkovitz' GMNX viewer playing the Lutoslawski example. Many thanks, Joe, for the provocation! See Issue #51. |
|
Sorry about changing this issue's title so much, but ideas have been developing very fast recently. I have decided to give this proposal a name (altMNX), so that I/we don't have to keep using circumlocutions. The altMNX specification proposes that this CG's goals (and more) can be achieved using standard SVG, but with a class and class-nesting structure specialized for different music notation types. (See #23) For example, CWMNX would be an SVG file containing an |
notator
changed the title
|
If I'm right, it should be possible to translate a MusicXML file into an SVG file that contains no instantiation. However: I am not a MusicXML expert. It would be best for me to demonstrate the principles (get this project off the ground), and then ask for help from the community (especially @joeberkovitz and @mdgood) in fleshing things out. MusicXML is a large specification, and its obviously going to take a little time to cover it all while deciding on the best ways to treat various features. I am going to start by translating a significant part of the FaurReveSample-MusicXML.xml file (to be found in the examples folder in the MNX repository). Once the chair understands how this approach works, and is convinced that it can be extended for the whole of MusicXML, we can take things from there. I think it will eventually be possible for such translations to be done programmatically, and that different translators will be able to cope with source files that make different assumptions (i.e. MusicXML that has been exported from different applications). To answer the points @joeberkovitz summarizes above:
No. Developers who are interested only in the logical structure of the file, only need to look at the class information and the information in the
I'm not sure that I understand this. If the app does not render the score at all, then it can't write out a transformed CWMNX score. I'm not focussing on "music editors" alone. As I outline above, its quite possible to treat a cwmnGMNX file that has no instantiation as being logically equivalent to MusicXML.
The goal of the SVG hierarchy is not to simplify the generation and display of the elements, but to determine their z-order. SVG elements that are written later than others (i.e. lower down in the file) are written on top of elements written earlier (in the z-order). I'm now going to start making an SVG file that is equivalent to a significant part of FaurReveSample-MusicXML.xml. I'll report back here when I think I've got something you need to look at. |
|
I am sorry, but it appears you continue to avoid answering these objections.
I sincerely doubt this claim is true given the need to weave semantic information into an SVG file. You need to prove that it actually is simpler, with a detailed example that encodes everything that CWMNX does. Note that the standard is being "properly fixed" in either case, so saying this adds nothing to the discussion. For my part, I'd claim that SVG is not going to lend more rigor to an encoding of semantic data, and will likely subtract from it since it was not designed for this purpose.
In which case, SVG is not serving any purpose at all, and using SVG as an encoding is a hindrance -- a bunch of empty groups with class tags and assorted injected non-SVG elements. I don't see any possible argument that SVG-without-graphics is a simpler package to deal with than straight semantic markup as currently proposed.
"Render" means the creation of graphics. So certainly this app can transform a score, by simply changing notes, clefs, etc. from the original, and writing them out without creating any graphics of the transformed score. (The original graphics would be lost in any such transformation.) But now it's clearer that you think SVG makes sense as an encoding even when there are no graphics.
This last point about incompatible hierarchies is a really significant objection, and I don't think you have ever understood it properly, or responded in a way that makes me feel that you understand it. You seem to have a naive understanding of the SVG hierarchy and of the overall design of SVG. Z-ordering is just one of a number of essential concerns. Please study the coordinate transformation capabilities of the The hierarchy also serves to group together elements with common interactive event handlers, and applications displaying SVG will not always have the same event-handling concerns to shape their hierarchy. So here too we have great potential for the force-fit of semantic parsing onto SVG to disrupt all the good things about SVG -- which are largely absent, anyway, if SVG doesn't contain any actual graphics! |
|
I said
That is, of course, overkill. Part of what one might call "creative thinking". What I meant was that it should not be necessary for a parser that is only interested in the logical information in the score to look at the precise locations in the instantiated elements.
You may be right, but I've been working with SVG so long that I think its unlikely. The only way to find out is for me to provide the concrete example of a cwmnGMNX score that @dspreadbury is asking for. Contrary to my previous posting above, I've decided to tackle this from the other end: I'm going to try to restructure the elements in the Aprés un rêve SVG file as cwmnGMNX, calling the namespace Let's postpone further discussion on this until we have something concrete to discuss. Of course, if you are right, and I find out that it really is impossible to do the conversion I have in mind, that will be the end of the discussion. :-) |
Now that you're agreeing that this is overkill, you're still not answering the fundamental objection: many applications have absolutely no need to generate graphics, such as the example of a command-line score transposition tool. Forcing such an application to package its output as SVG makes no sense. You are left with two alternatives, both of which seem unacceptable on their face: 1) emit SVG with no graphics and only semantic information, or 2) force all applications to include a graphical rendering in their output, even if they neither need to consume nor produce graphics. When you work up your concrete examples, please be sure to prepare something that addresses this set of use cases. |
|
A note on process, not on content: You asked us to postpone further discussion until we have something concrete. The chairs cannot postpone discussion of this issue for very long, because work on the spec must continue, and this issue proposes to abandon the current direction and go somewhere very different. We expect to move in short order on resolving this issue one way or the other in the next few weeks. Therefore all materials in support of your argument should be provided ASAP. You've been raising this issue in one form or another for nearly a year, and the work of the group cannot accommodate an open-ended timeframe in which the issue is continually brought back to life. |
|
I've prepared a more complete example that shows exactly how the current MNX spec supports a combination of SVG and semantic CWMN data. This can serve as a basis for comparison with alternatives that somehow pack CWMN into SVG, as this issue proposes. No spec changes were required; this is simply a further buildout of the existing GMNX materials using the The example lives here, with comments included: Here is a brief summary of the approach.
The key advantages of this approach are:
When a concrete alternative is proposed, it should be compared against the speced proposal in terms of these objective advantages. |
|
@dspreadbury asked
I've now uploaded two files: FaurReveSample.cwmnNoGraphics.svg and FaurReveSample.cwmn.svg. It is just as easy to retrieve the CWMN semantics from my SVG files as it is from FaurReveSample-cwmnx.xml. These files therefore support flexible and dynamic formatting of the score. (There's a more detailed explanation of how this works below.) FaurReveSample.cwmn.svg (the version with graphics) is structured in the usual SVG way, with both Namespaces are a standard mechanism for including foreign data in SVG files. Once a Elements that are going to contain SVG drawing instructions cannot be prefixed because that would prevent SVG renderers from seeing those instructions. Such elements are therefore redeclared as gets translated to the following SVG There is a note at the top of the FaurReveSample-cwmnx.xml file to say that it is not complete. It is therefore very possible that I've made mistakes when filling in the blanks, or have made debatable choices at some points. But I don't think that's a serious problem. The point is, that however CWMNX turns out in the end, there will be a way to translate its semantic information into a form that can be included in SVG files. That means, in turn, that I am in no way trying to upturn the CWMNX debate.
My concern is with the delivery of the semantics, not their content, and with the extra power that semantically enhanced SVG would give to programmers. SVG instantiations enable an important set of use-cases (web applications, performance, synchronisation etc.). Analysing the Finale plug-in's completely unstructured SVG (FaurReveSample.svg) was no picnic! :-) I'll reply to @joeberkovitz in a separate post. This one is long enough already. |
|
@joeberkovitz (in reply to your most recent posting): Basically, my objection to the current version of the As I have demonstrated in FaurReveSample.cwmn.svg, there is a straightforward way to write CWMN scores in SVG, together with the cwmn semantics you are developing for Notations other than CWMN (that use a different container hierarchy and semantics) can be treated in a similar way, by defining a corresponding namespace (e.g. To reply to the "key advantages" you see in the current approach to
I think the SVG needs to be disrupted (enhanced with semantic information). The applications that author the SVG have all the necessary information to be able to embed the graphics in the semantics.
Applications can, of course, change the z-order if they know what they are doing, but it would be a good idea to agree on some sensible defaults.
The usual way to create semantically enhanced SVG will be to use an editor that understands both the graphics and the semantics. Any SVG-editor worth its salt ought to preserve any namespaced data that it does not understand. Even Inkscape does that!
That's a problem, not an advantage. How is the client software supposed to know what is in the file? In other words: if you want to define areas in the SVG without looking inside the SVG, you will have to do more (one-off) work to do so. It would be much easier to have all the synchronisaton information already present and parsable in the file.
I've provided an example of an empty SVG file that contains the same semantic information as in CWMNX. Such files would use the same semantics-parser as for non-empty SVG files.
Applications that create SVG files can format them in any way they like. I see no problem in creating different instantiations of a particular score for different purposes.
There are ways to automatically validate XML files having multiple namespaces. Its not easy, but it can (apparently) be done. This is a problem that would only have to be solved once, thank goodness! |
|
The co-chairs have discussed this issue at length and offer the following summary of their objections to the proposal here to use SVG as the carrier for both CWMNX and GMNX data. The burden of using SVG as the carrier for CWMNX data is too great. When opening “altCWMNX” files, applications that do not want to render graphics at all, or can render graphics themselves from the semantic information in the file, will have to work harder to ignore the irrelevant SVG elements; when writing “altCWMNX” files, these kinds of applications will likewise have to write irrelevant SVG elements. Forcing all applications that want to work with CWMNX data to also work within the SVG graphical schema is unacceptable to the co-chairs, even if no actual graphics are included in the document. The “altCWMNX” proposal can not address many of the use cases that the group has identified as important, as detailed in this previous comment. SVG can provide one or more static instantiations of semantic musical data, but it cannot provide the kinds of dynamic, flexible layout and formatting demanded by many of the group’s target use cases. Not supporting this many of the group’s target use cases is likewise unacceptable to the co-chairs. Finally, the proposal runs counter to the group’s agreed charter: the charter states that the group will define two formats, CWMNX and GMNX, as well as the MNX container format, and the direction of the group’s activities was agreed by consensus and discussion over a long period of time. CWMNX was specifically agreed as a semantic format, using a definition of "semantic" that we agreed on as per issue #50. Combining CWMNX and GMNX into a single format, and using SVG as the carrier for that musical data, is outside the scope of the group’s charter, and is hence unacceptable to the co-chairs. The co-chairs propose that this issue should be closed based on the above objections. Since the co-chairs already understand @notator’s position, the time has come for other members in the community to provide input and have a chance to speak on this subject. |
|
I agree to definitely NOT use SVG as the carrier for both CWMNX and GMNX data. It makes no sense to use a format with a graphical static nature as the carrier for music. |
|
I have been following this issue as an observer for quite some time. I hope I'm not speaking out of turn with my first comment here, but some 30 years ago, there was a proposal that, because of the hardware expense, we all learn to read so-called computer-compatible digits. That taught me the lesson about circumscribing approaches to present perspectives, limitations, or expense. So I don't agree that systems and developers in 2018 should limit their approaches. @notator has been in touch regarding one of my scores that may help make his point perhaps more effectively than some of the examples so far, though I'm not sure he will have the time to do that if the issue is closed soon. Please fee free to delete this comment if it's inappropriate. |
|
It would make my life much easier, as a creator of music analysis software that for the most part does NOT directly deal with the graphical representation or audio performance of a score, if I could simply ignore all |
|
I agree. @notator, the purpose of the CWMNX format is not supposed to be primarily a graphical interchange, since a large portion of the use cases have to do with changing the graphics (reflow), altering the music without display (transpositions), producing audio only, or displaying on alternate platforms and screen sizes. I, for example, work directly with GDI for display in our music editing program. All the SVG display information would be ignored by my system when importing a score, even though I AM displaying the music graphically. In addition when exporting a score, I'd need to completely rewrite my display commands to produce SVG. Or, I could produce no SVG (as you suggest) in my exported file, in which case I might as well be producing an XML file, which is easier to validate than an SVG with class and namespace tags. I think it's great that you have found a way to produce SVG from the CWMNX spec, but I think that the SVG system you have created needs to be a consumer of CWMNX and not it's main carrier. --Christina Noel |
|
@dspreadbury said:
I will reply to the co-chair's objections in detail below, but I'm afraid I don't think you can/should close this issue completely. It is the only place where any serious discussion of GMNX has taken place, and there are a number of outstanding issues there. If you close this issue, you (or I) will immediately have to open a new one to cope with those issues. An even better alternative, if you close this issue, would be for you to open a separate repository for GMNX. That way you could keep me out of the CWMNX discussion, and we could all keep better track of the GMNX issues. I take @clnoel 's points (both here and in #2): Using SVG as the carrier of semantic information for CWMN would make the huge body of existing CWMN software unnecessarily complicated. So we can forget about that idea. I currently don't really understand the issues raised in #2, and am eagerly awaiting @joeberkovitz' continuation of #57. His FaurReveSample-cwmnx.xml crucially omits the page-layout information, so I need to see that in order to update my FaurReveSample.cwmn.svg. There may well be lessons to be learned for GMNX notations as well. To the chair's objections in detail. @dspreadbury said:
Point taken, and accepted (see above). As I said above:
Apropos: I think the chair is dodging issue #23. This ought now to be under Active Review. @dspreadbury again
This is covered by my acceptance of the objection in the chair's previous comment. @dspreadbury again
As detailed in #23, the Charter does not include implementation details for any of these formats, so we are not bound to accept @joeberkovitz' current proposals. I think the MNX container is likely to be redundant. Would it, for example, impose the same kind of unacceptable burden on legacy software as the use of semantically enhanced SVG? Re @Kalvos' remarks: |
|
So, perhaps, this proposal with svg grouping and container classes will be the way we properly do gmnx, which is still very much in the early stages of formation. Since cwmnx will also need to be represented in gmnx, the systems that @notator has created to make an svg will be the necessary "converter." Because gmnx is necessarily representing graphical scores that should never be reflowed, as well as music from other cultures that would have different reflow rules than cwmn has, we would not worry about those kinds of use cases when in gmnx, but would rather be dealing with a "static" instance, which svg is very well equipped to represent. In which case, this particular issue should be closed, since we won't be taking cwmnx into altmnx. But @notator is also right about either needing more issues or another repository. GMNX is not getting enough attention, and part of the point was to finally pay attention to it. I really don't want to fall into the trap of hitting CWMNX hard and trying to perfect it and leaving GMNX as the place that we just sort of shove things into to get them out of the way. Christina Noel p.s. I don't personally know much about the modern music notation systems, or the needs of other culture's music, so if I overstep or assume something in my ignorance, please educate me! I love to learn! |
|
btw -- am I the only one who has trouble following what all the MNX beyond simple MNX mean? Would it be better to call them "MNX-Classical" "MNX-Graphic" etc.? |
|
It's great to see more discussion of the question at hand about CWMNX and SVG. I'm only jumping in here to make assurances about the future of GMNX, not to repeat my earlier observations about the altMNX proposal. It would make me very happy to see the group as a whole pay more attention to GMNX. My personal background didn't seem important to relate before, but perhaps it's worth mentioning briefly. I'm a composer whose work includes many non-CWMN scores, and this was my first, decade-long profession before working as a software engineer and architect for the next 35 years. I have a conservatory education, not a computer science one. And while I'm best known for founding a company (Noteflight) whose success is all about CWMN, that doesn't fully reflect my motivations in working with this group, which are very much aligned with composers working at the edges of what is possible, and with musicians in other cultures who do not employ a European framework for thinking about music. So GMNX is profoundly important to me, because it seems like part (although not all) of a notation solution that can be culturally and historically neutral. My combined background doesn't make me right about everything, needless to say -- but it does speak to the reason why I proposed GMNX in the first place. I desire to see it succeed, while remaining founded on the best possible principles of software architecture. The other chairs value it also, and I hope and expect we will have more GMNX issues to discuss than we do today. (At present there are about ten). To wind this up, I've just added a couple more GMNX issues (#74 and #75) to reflect some of the side points made above, because I want these discussions to be guaranteed a life outside #25. Note that the SVG-grouping-class-name issue already exists as a separate issue, #28, which deserves its own discussion. |
|
@joeberkovitz |
|
@mscuthbert Possibly. As a programmer, acronyms come easily to me, and I tend to store them up. FYI to those who were also confused by this discussion, CWMN is "Common Western Music Notation", so CWMNX is our new encoding scheme for that. It's my understanding that GMNX is "General" MNX (not "Graphical"), meant to be a scheme by which ANY music score could be visually and audibly reproduced, regardless of culture of origin. Perhaps, to avoid confusion on that last bit, we rename it GenMNX? It's just as fast to pronounce and moderately clearer in meaning. Christina Noel P.S. On a side note, and this is probably the wrong place to ask this, is tablature notation considered part of CWMN for the purposes of our discussions, or will it need it's own representation? |
|
Contemporary tablature is part of CWMN / CWMNX. Hopefully historic tablature styles can be supported as well - at least as well as in MusicXML if not better. |
|
@mscuthbert @clnoel Issue #74 exists to carry any forthcoming of better names and explains the rationale (however faulty) for the current names. Let’s carry on the naming discussion there, rather than here. @notator Issue #75 has been created as a venue for community discussion of the question of a separate GMNX repo. |
|
The co-chairs agreed today that the community feedback regarding this issue #25 is clear and that the objections to packaging CWMNX in SVG stand. We are therefore closing this issue. We appreciate the original proposal, as well as the healthy discussion that has taken place. The chairs would also like to append the following additional observations, looking towards the future:
|
|
Thanks, @joeberkovitz for giving me permission to write to this closed issue. We also know that semantically rich instantiations of I continue to think that SVG instantiations must play a central role in any effort to integrate music notation into existing W3C standards, and that SVG namespaces are the mechanism by which to differentiate between the necessarily different semantic structures of the various notations. |
I think the GMNX stucture described in §8 of the current proposals document (26th April 2017) needs to be turned inside out.
The W3C already has a natural match for a page of a score (an SVG document) and a standard container for such SVG pages that can represent a score (HTML). I think its a mistake to try to re-invent the wheel. We need to take full advantage of all the existing technology for parsing such files.
Here, for discussion purposes, is some skeleton code showing a) how both MIDI information and media files might be synchronized with the SVG graphics, and b) how synchronized cursors could be realized in scores containing any type of music notation.
begin Edit 16.01.2018
Cursor handling is currently being revised. See the Cursors Issue below.
end Edit 16.01.2018
Note that the svg/data-scoreType attribute tells the client application the type of the notation written in the file, and that corresponding semantic information for the SVG elements is provided in their class attributes.
This code sample contains some extended comments. The best way to read it is to copy it into a proper code editor.
The text was updated successfully, but these errors were encountered: