Skip to main content
Topic: MusicXML (Read 13004 times) previous topic - next topic

MusicXML

Are there any plans on developing support for MusicXML in Noteworthy in the near future?

Thanks!

Geoff

Re: MusicXML

Reply #1
Geoff, I don't speak for Noteworthy Software (I'm just a user). But it's my understanding that MusicXML is primarily for web page graphical representation of music notation? That might not be NWC's primary customer base.

Re: MusicXML

Reply #2
That wasn't my interpretation at all... As I understand it, it is designed to be an interchange medium, which certainly could be used (in conjunction with the appropriate [most likely java-based] programs) to represent scores graphically.  However I understand it to be more of a "common language," somewhere along the lines of MIDI except more robust and geared more toward representing scores as written rather than as sounds.  I think that Noteworthy would probably be fairly simple to convert, since most of the things in Noteworthy (ie slurs, staccatto marks) are attached to the notes, which after my (admittedly brief) perusal of the MusicXML structure is the same as MusicXML.  I, personnally, would like to see such an interface language become standard, especially when transferring between (say) Noteworthy and Sibelius (or Finale, Encore...).  It would save me a lot of time since it would mean I could use one program for what it does best (input), and then transfer to another for what it does best (printing), without losing all the aformentioned slurs, staccatto marks.)

Geoff

Re: MusicXML

Reply #3
Thinking along those lines ...

An eighth note at pitch C4, stem up, standard notehead, unbeamed/untied/unslurred is a fairly well-defined thing. Would that suffice for a note description in MusicXML, so that the user agent (interpreting program) would decide (for example) how long the stem lenth should be, and how tightly packed (horizontally) the note should be, relative to its neighbors?

In the case of a slur, would it suffice to indicate the beginning and end notes, or would more info (up/down, degree of concavity, line thickness) be needed?

My thoughts are wnadering here, because in the world of browsers and plugins, for example, there have been many incompatibilities among "standards compliant" things, especially when object from supplier X is installed into host from supplier Y. The world of browsers is where XML-type languages have, I believe, made the most progress.

I can see that maybe in 5 or 10 years, XML will be more standardized for all purposes. But in the intervening time, I can imagine XML-wars the way that the mid-1990s saw browser wars, and even Java wars.

My point: I don't think that without a consortium (and, maybe even with one) music software suppliers are likely to find a useful, common XML standard. Someone brings up the topic of "NIFF" once in a while; as far as I know, that hasn't gone very far.

Re: MusicXML

Reply #4
Well, let's see what I can do here...

(Omitting the document type declarations...)

<measure number="1">      // First measure of this part
// (Part definition omitted)
<attributes>          // Begin defining measure attribs
<divisions>2</divisions> // Divisions of quarter-notes
// In this case, divisions of 2
<key>              // Key
<fifths>0</fifths>  // Based on circle of fifths, ie C
</key>
<time>              // Time sig
<beats>4</beats>
<beat-type>4</beat-type>
</time>
<clef>              // Where are we?
<sign>G</sign>    // Type of clef
<line>2</line>    // What line is it on?
</clef>
</attributes>        // I believe most of the attributes can be defined once, and redefined when a change is needed
<note>                // Yay!  The actual note!
<pitch>            // Pitch
<step>C</step>    // Step, ie ABCDEFG
<octave>4</octave> // Which octave
</pitch>
<duration>1</duration>  // How many divisions long?
// In this case, 1 in divisions of eighths, so an eighth note.
<voice>1</voice>    // Which voice, n/a in Noteworthy but certainly in Sibelius
<type>eighth</type> // This is the symbolic note-type.
<stem>up</stem>    // Stem direction.
</note>
</measure>

Simple enough, eh?  Of course, this would be part of the output of a good converter (minus comments, surely), so you wouldn't have to worry about writing this yourself.  For slurs, I think all that's currently allowed for is the first note, continuing notes and the final note.  Certainly some readjusting would be neccessary once your file has been imported, but that's true even if you enter it by hand.  Each program has varying levels of precision in such matters, and Noteworthy doesn't allow for much more than the standard does.

XML is standardized, but keep in mind that it's just a set of very specific rules for creating markup languages, not a language itself.  MusicXML is also standardized.  It has a very specific definition (well, actually 2) that is controlled by one group (Recordare).  You should take a serious look at it.  One of the DTDs is here: http://www.musicxml.com/dtds/partwise.html and you can get to the main site here:  http://www.musicxml.com/ .

By XML wars, I assume you mean waring factions touting different XML-based languages as _the_ solution to life's problems (You mean the browser wars are over?  Why did I bring my laser-pistol, then?).  That is certainly a possibility.  BUT, the largest problem, as I see it, and, again, I've been wrong in the past, was each individual party adding features to their own browser but calling it "html" still.  I think with a more centralized definition (plus the requirement that XML-based language readers error out if the syntax is not correct), that will not be so much of a problem.  (Of course, some will still try to add to the definition, but for their programs to be compliant, they would have to invent a new DTD, including the new features, and each file would have to clearly state which DTD it's using and where it can be found.)  (Ideally m$ goes belly-up in the next week or so, but since that's not likely...)

Anyway, yes, you bring up good points... Centralized definitions are key (but it's already in place), there are many attributes that some programs use and others don't, however these are largely left out of MusicXML (degree of concavity for slurs, etc).  As for a consortium, I don't think it's neccessary for a group of companies to form one, but rather a group of users that can make a statement with their purchasing dollars (restraining self on issue of capitalism...).  And NIFF... as I recall, that was a graphical representation.  But, as I believe is mentioned on the MusicXML website, why bother with just graphics?  Why not buy a book, or use a PDF (which is another thing... PDFs are very common nowadays, was there a consortium of companies developing them?  (I really don't know, but it was just Adobe, right?)  If a leader in the notation field - unfortunately not Noteworthy - were to incorporate something like the MusicXML, it could set a standard.

I know that there are programs already that can translate Finale files.  It might be possible to have a group of users release a conversion program for Noteworthy (and other programs), if the file definition(s) were(is/are?) available.  Unfortunatly everyone regards their file definitions as top-secret.

I think by this point I've gone on long enough.  I hope I answered some questions... please, let's continue to discuss this.

Geoff

Re: MusicXML

Reply #5
Grr... it collapsed my nicely-spaced example.  Oh, well.  You can still read it

Geoff

Re: MusicXML

Reply #6
Thanks for the references. I have been dealing lately with a lot of nonstandard standards. as you can tell!

Re: MusicXML

Reply #7
There is a program, abc2nwc available on the web so somebody must know the NWC file format.
Since 1998


Re: MusicXML

Reply #9
Eh, okay, so that's not it, or if it is, I can't make sense of it.  But I've started my own... should be interesting.

Geoff

Re: MusicXML

Reply #10
I had a go at it a while back, and figured most of it out, but that was version 1.5x, so the format's changed now. That's the problem - since the format is proprietary, if you figure it out now, it may well change in future formats.

Hint - it's compressed by default, so either save your test files as uncompressed, or decompress the files on the fly (easy if you use Java, as I did).

Given that the format is proprietary, it would probably be naughty of me to tell you what I found out, quite apart from the fact that it's out of date.

RObin

PS to Noteworthy - I hope this isn't in contravention of the licence or anything - I only did it for my own benefit, and have no intention of using the information commercially.

PPS to Noteworthy - It would be nice if you put the format in the public domain, though! You could still reserve the right to change it without notice.

Re: MusicXML

Reply #11
Having said all those things about proprietary formats, the reference you give seems to describe it pretty fully, although it doesn't say (correctly) which version it covers (version 2? - have they got an advanced copy or something?).

Anyway, if you're having difficulty understanding that description, rather than just having trouble matching the description to actual files, I would suggest that trying to reverse engineer the format yourself might be a bit advanced.

Having said that, if you just meant that it doesn't match your files, try again with uncompressed files.

RObin

Re: MusicXML

Reply #12
Yeah, near as I can tell, it doesn't at all match my files, even uncompressed (I realized even before I started my best chances would be with uncompressed).  I don't see anywhere where it mentions the margins (which are extremely noticable), the font types (like staff bold, staff italic, user 1, 2), which are also pretty noticable.  I'm trying to determine the scheme used for number of staffs, but I think I have the staff declaration areas pinned.

Anyway, that's what I have so far...

Geoff

Re: MusicXML

Reply #13
Now that I've got home, and had a chance to look at it, it's obviously a very old version - probably about the same vintage as what I have, although I didn't figure it all out - I gave up before I got all the way. Still, it's a useful starting point. If you start playing with the bits that aren't mentioned - number of lines on a staff is another recent addition - you should see what changes. That's the way I did it - start with a totally empty score, then add bits one by one and look for the changes.

RObin

Re: MusicXML

Reply #14
There is a selection effect on this, and similar forums (fora?). Participants re most likely to be those who are very comfortable with the Internet. Those who primarily use if for e-mail, or the occasional click-here browse, are less likely to have their voices heard.

Among the local singers where I live, two others (to my knowledge) have NWC. both of them are competent, lifetime musicians (beyond singing), unlike myself. Both have Internet access. Both use AOL, for virtually no purpose other than e-mail. One of them didn't know that there were any updates to any software since her son bought her a Windows 98 computer, probably back in 98. (She got NWC as a gift.) The other one knows that computers and software change, provided that someone else does it for her.

Both of them, I believe, are in the primary target customer base for NWC.

What I am saying is that forum users often request features - XML, scripting, etc - that are the requests of programmers and Internet users (who also are musicians), rather than the requests of general musicians and music students.

This comes to mind because I also drop in on another music forum, and about the same time this thread appeared here, someone else was asking about MusicXML over there.

Re: MusicXML

Reply #15
... indeed, as I write this, the current user site (featured on the NWC main page) was written using, believe it or not, MS Word, rather than an HTML development tool.

Note to future readers of this thread: The featured user site changes from time to time.

Re: MusicXML

Reply #16
HTML Development Tool?  *shudder*  'Course, maybe hand-coding's why my pages look so bad... no, wait, it's 'cause I have no sense of style...

And you're probably right.  The general users of this program  aren't going to be the terribly techno-savvy.  Nevertheless, I still feel that a conversion tool that would allow access to more scores would be useful.  So, I've set myself to making one.  Dunno how long it'll take, but I'll get there someday!  (And by then they'll have changed the file format, an' I'll have to start all over!)

Ah, well, anyway I'd better get going...

Geoff

Re: MusicXML

Reply #17
Now, that's motivation! Incidentally, I still use a prior-generation visual HTML layout tool to position things. Fortunately, it writes easy-reader code. Then, I manually edit it and add script, etc. Finally, I use an HTML syntax checker to find my errors.

For those forum readers who wonder how HTML got into this: Obviously you have Internet access, or you wouldn't be here, unless you're reading the forum off-line. Many (amateur) music composers like to present their compositions, visually or audibly, on-line. This is for the enjoyment of their hopeful world-wide audience. In the bad old days, if you wrote your own piano score, and if you were a competant piano player, maybe mom and Aunt Tilly would get to hear it. If you were less than competent at the piano, maybe just mom! But now, you can write your composition, have it played by the ever-skillful computer, edit it, and post it on the Internet. Even if only a few dozen people find it and listen, what an ego boost!

So... it is worth knowing how to use HTML to do this.

Re: MusicXML

Reply #18
Geoff, any luck figuring out the file format?

The format I found listed somewhere doesn't correspond to the any files I have, I don't know how out of date it is.

Do you know the compression algorithm?

Re: MusicXML

Reply #19
RE: The Braeburn Software Noteworthy file format.

The Noteworthy format referred to on the site is the format for a notation processor produced by Braeburn.

I believe the first version of NWC was called Noteworthy but had to be changed to NoteWorthy Composer to avoid confusion with the Braeburn software.

This is probably listed somewhere in the NWC history - Eric can confirm.

Re: MusicXML

Reply #20
So all the time we were looking at a spec and files which didn't seem to correspond to each other at all, not realising there were two formats for two totally different programs!

I hope someone figures something out for NWC files, but I don't like our chances. We'll just have to send our files to someone with NWC to be converted and sent back.

I looked around and there appears to be two distinct programs ABC2NW and ABC2NWC. The former, on its webpage, puts a link to Braeburn's NW format, while the latter was created by ABaCus music, evidently by someone who does know the NWC format. So perhaps its not that hard.

Re: MusicXML

Reply #21
For the benefit of other readers of this forum: There is an "Eric" who works at NWC. But I am not aware of him using the name "Eric" if he replies to this forum. I believe that the "Eric" of this thread is a user of that name - another person.

Re: MusicXML

Reply #22
Regarding the file compression algorithm - the Java ZipInputStream class handles it with no problem, which means it must be the Deflate algorithm used in the open source ZLib and GZip formats (says he more or less quoting from the Java documentation).

RObin

Re: MusicXML

Reply #23
Hi, all...

Yes, I am making progress in figuring out the file format.  I've got (what I consider) a good portion figured out, but I still have some to figure out with notes, as they're quite complex little buggers.

If the decompression algorithm is in fact the Gzip algorithm, then I should be able to run compressed or no through (once, of course, I actually get around to writing the program), otherwise folk's'll have to save as uncompressed when they want to convert; not too bad I don't think.

I'll keep you all posted, but this week is midterms so I'm a bit busy right now.  It should settle down again in a couple weeks.

Geoff

Re: MusicXML

Reply #24
It is not unreasonable to require that users use the uncompressed format, for your purpose. They can always open an already-compressed file in NWC and re-save it uncompressed.

I suggest (my personal suggestion, for what it's worth) that you start by limiting yourself to really basic things, something like one staff or two, no modified notes, no grace notes, no ties or slurs. Maybe that limits it to "Twinkle, twinkle, little star," but it would give you a chance to get feedback from prospective users.

Mind you, you are also more likely to get wish-list requests from persons who can't figure out XML anyway!

Re: MusicXML

Reply #25
Geoff,

If you want, e-mail me on Robin-at-RPWithey-dot-info, and I'll send you what I found out previously. It's out of date, but it might be of some use.

RObin

 

Re: MusicXML

Reply #26
 
NoteWorthy is the former name of Music Publisher, produced by Braeburn Software (Bernard Hill).