At least the two standard songbooks of the Lutheran church in Germany don't place a hyphen at the beginning - see two attached examples.
I managed to do it with a "whiteout" trick - see first staff in the attached example. The idea is:
Place an XText object with Class StaffSig (so that it occurs on each staff), with a white text that covers the hyphen.
Some details:
You need to set one Highlight Color to white (in Tools->Color; I always use "Highlight 4" for this).
The text is "%0x2588% ", which is the "block character" (a black rectangle) and three spaces, with Justification Right so that it extends to the left. With multiple lines of text, you maybe need "%0x2588% %br%%0x2588%" or the like (i.e., blocks separated by line breaks); I have not tried this.
For positioning, you shift this XText up and down (position of the XText) and left and right (number of blanks in text) until it covers the unwanted hyphens.
Then you change the color of the object to "Highlight 4" (or whatever your White color is)
A kludgy workaround, but might help in some cases ...
In case you have multiple layered staves that make up your single visible staff, you must add a bar at the beginning of each staff, otherwise the distance computation will not place some leading items (clefs etc.) at the same position.
NB: When the staff is broken for printing into multiple systems, a single bar will be present also on all following systems. But this is a special behaviour that works only for a single barline - putting e.g. a double barline as first item on the single staff will not repeat it on following systems.
But what do you do when you want a single barline only on the first system? (I would know no good reason for that, but what do I know ...): You add an invisible grace rest before the single barline. By this, the staff no longer starts with a single barline, and the special behaviour copying the barline to all systems does not fire.
Tried it (needed a MusicXML for a colleague with another program).
1. A bug? In the resulting MusicXML, when opened with Musescore, the barlines of 1st and 2nd stave are connected; but not in the NWCTXT. Also a test conversion with https://nwc2musicxml.appspot.com/ does not connect them.
2. Eighths are not beamed in NWCTXT, but are beamed in the result (also with https://nwc2musicxml.appspot.com/). Would it be possible to suppress auto-beaming in Musescore via some info in the MusicXML?
Yes, you're right - adding "learning support" is definitely useful and valuable, even if (or exactly because??) it "only" shows steps on which to build more knowledge*. I don't have time right now, but this would be interesting to write
* We also have a tool "Note Names in Staff" - certainly not the most important tool to use, but nice, nevertheless.
No, probably not - just the knowledge necessary to develop the algorithm.
Mhm. Being a software engineer, including theoretical background, and - hopefully - having a little bit of musical knowledge: I'd argue that there is no (useful) algorithm. Look at my first example (Bach): The sixteenth on "bin's" is a musical decision that stresses the "nicht" some more - I'd say no algorithm would do this (whether it's ok or not ...). Maybe some sort of AI would be able to do this ...
However, the main problem with playing figured bass is, in my humble opinion, voice leading (as with all chord writing): Putting a following chord is always also a melodic enterprise, including decisions about leaving out notes; using typical patterns, most important, of course, countermovement - at least of outer voices; deciding how much movement there is in the chords - one-on-one movement, i.e., one chord per number, is typical, but also arpeggiated chords may be an option. A very wide and, I'd say, "under-determined" (in the mathematical sense) area ... so algorithmic solutions would probably have to be quite inventive, at places.
But, being a hobby musician, I don't see why I would want an algorithm to do this at all: Doing, and learning, it myself is the whole fun!
Just for fun, here is another example, which uses a few more symbols. When you open the attached NWC file, you see only the bass line - you can try to decipher it, i.e., write the expanded chords manually in a separate system. I have given an example expansion in another staff, which you can - then? - make visible and check your (and my!!!) expansion.
How, on earth, can one play this from "just the numbers" in real-time?? First, it's actually ok to just ignore almost all numbers! The only ones you must watch out for are 4 and 6 without 3: - 6 alone is a sixth chord (sure); - 6 and 4 is a 64 chord (ha!). - 4 alone or with a 2 is a some sort of fourth - if there is a 3 later, then it's (was) a suspended fourth; if not, fine, you just played the fourth of a dominant seventh chord. Otherwise, just play a normal triad on the bass note. This will work almost always. If in doubt (or panic), just play nothing in the right hand ("t.s." = tasto solo).
Second, music in those periods used lots of standard patterns - thus, one could risk to just "play by ear with some number-checking".
Last, learning those "changes" is also not that hard - practice, practice, practice, and it will come as second nature.
I typically write figured bass with Texts and XText.hmm objects; I have attached an example rewriting this excerpt from Bach's St.John Passion from Wikicommons:
... There seem to be several styles, so one of the first questions a potential object coder might ask is, which style(s) are needed?
All German notation is heavier on strokes, whereas elsewhere # was used routinely. The meaning is "by convention" and ambiguous; e.g., # can either mean "with sharp" or "a semitone higher" - which is formally different if the degree indicated has a flat in the current key; but in practice it might mean the same: Remove flat.
Playback is, IMHO, (also) impossible because we are talking about improvising music! What might be possible, is a tool which creates a rough chord expansion as a basis for writing the filling chords.
a) Install the NWC2STDA font to Windows (only once). - When you install NWC, the font is not installed for Windows (and therefore for Word). Installing can be done by ** opening Windows Settings (via Start button), go to Personalization,then Fonts: ** open Windows explorer at C:\Program Files (x86)\Noteworthy Software\NoteWorthy Composer 2\Fonts ** drag NWC2STDA.ttf to "Add Fonts" on the Settings window.
b) Open Microsoft Word or OpenOffice Writer
c) In NWC, open "Print Preview"; hit F11 - you will see that the justification is switched off (see attachment what this looks like)! ... and then Ctrl-C
d) In Word or Writer, hit Ctrl-V: The score will be inserted as a (resizable) image. You can now save/print this document.
This is easy and quick, especially for only 1 or 2 pages.
By default, NWC does it wrong for the second measure of 3/8 example; and also if you manually fully beam the 6/16 example. However, in the last case, NWC at least does auto beaming correctly by only beaming together the eighth and the sixteenth, but leaving the dotted eighth without beam. And of course and thankfully, one can reverse the fractional beams by using the "Beam group start" option on the sixteenths ... see other attachment for all of this.
It seems that the definitive source for notation rules is "Behind Bars." I assume one needs to buy the paper book ($74 on Amazon) or Kindle version ($41) to use this reference work. Are there references online?
I'd say $41 is extremely cheap for all the information you get (about a full tank of my car - from driving around for this amount I learn much less).
V.0.3 added in root posting, replaced examples in second posting: - Corrected access to bool properties - PrintVariation.hmm modifies previous items (so that it is useful for spacers). Because of this, PrintVariation 0.3 is not compatible with previous versions. Also, its properties as well as the internal storage for complete measure replacements have changed.
The object is still buggy with text properties of user objects - strange things happen there, as NWC sometimes (or always?) adds quotes. I do have an idea how to repair this, but it's more work than I hoped.
The meaning is "play c-sharp and c-natural together" - it is in "Behind Bars" on p.50 under "Altered unisons".
On the piano, c-sharp is the same key on the keyboard as d-flat, so my alternative notation above (the first one) definitely sounds the same; and is, I'd say, more easily readable - so I don't understand why it is written with this (quite new, I'd say) "altered unison chord notation".
See attachments for meaning (assuming that the clefs are treble and bass on the two systems), and how to create this with Arpeggio.ms and Markup.rg. I am not sure why this is written like that - is this for harp? - then, I guess, it has to do with the pedal settings that one would not write it with d-flat (however, I'd have guessed that especially for harp one would write it with different diatonic notes ...).
(However, I don't really understand what's going on: Neither NWC's nor Windows's character map show this symbol - and many more - in Times Roman on my Win10 installation; but the symbol is obviously available, i.e. it shows up in my NWC score ... hm. Edit: The answer is font fallback and font linking, as remarked by Mike in this posting from 2017 - thanks!).
There are more breath mark symbols than the "comma" provided by NWC: At least some sorts of V-shaped symbols and tiny vertical bars are also used in vocal and brass scores. Because I don't want to search all the time for the necessary characters in some text fonts, I have assembled a very simple object that draws some of these forms.
The vertical position of the symbols is such that objects at staff position 0 put the symbols (hopefully) at the most useful, standard position, also for staff with more or less than 5 lines. The small vertical bars are always on the top or bottom line of the staff (even if the object is moved up and down).
... that the Sibelius version is far more readable by a performer.
I think we only differ in words - I am very much with you that the spacing and sizing algorithms of NWC could use somewhat improved parameters; maybe would then need (I don't know the internals) changes to these algorithms; and, finally, require a few (but hopefully not too many) control parameters for (probably) pages, systems, measures, symbols.
In my dictionary (but maybe only mine), this does (or rather did) not fall under "further development" - because I suspect that the algorithms and parameters and defaults of NWC's sizing and spacing are, or at least were, intentional: "Developing them further" would require a modified specification.
But I can see what you need.
Minimal remarks about the two scores: The 16th beams in the trumpets in m.3 and m.7 are definitely wrong in the Sibelius score. I'm also not sure why both a tie and a slur are necessary in m.9 in trumpet 2. For the overall readability, yes, I have the same problem as an organ player - also there, the score is quite far away from my eyes; but a larger staff size in NWC requires too much horizontal space = too many systems and pages; contracting everything with spacers is not really an option ...
Edit: I have added an animated GIF comparing a part of the two scores. For my eyes, the main difference is the "boldness" of the noteheads. It seems that NWC's heads are a standard (quadratic) ellipse, whereas Sibelius uses an ellipse of a somewhat higher order - thus, the heads still fit exactly between the lines, but are "optically larger". NWC's SwingDings font seesm to do something similar - so the question is: Can we create and use a font from the normal NWC2STDA that has the head boundaries of the NWC2SwingDings font?
And I fear Windows 11, and 12 and... (Timeo Danaos et dona ferentes!)
Why? Since WinXP at the latest, Windows has been the most locked-in operating system out there - there are millions of "no longer supported", but vital programs for and inside all sorts of companies: "Compatibility" will remain the most important feature for decades to come. Moreover, even if some programs start getting hiccups, VirtualBox or the like will keep WinXP etc. alive forever.
...unless further development occurs, I will have to continue to move more and more of my work to Sibelius....
Can you explain why? My needs for musical notation do not change over time, so I have no need for "further development" (same for e.g. the text editor I use - a version of UltraEdit from around 2005, I think; and quite a few other tools). I see this development in Capella, but all what they do is part "featureitis", part things I simply do not need.
What I would like (but also not really need), is a program with a much larger scope regarding multiple movements; and with intricate sound creation not via soundfonts, but VSTis (which, AFAIK, Sibelius can do). But this is not "further development", in any sense, but a new product line ...
This is the second year we had to cancel our choir's advent concert - we had rehearsed a longer composition "Weihnacht" I had written - with NWC, of course - which would have been nice to sing and, hopefully, listen to. So, next try next year!
V.0.2 added in root posting: - Code to access staff name in 2.8.x (per Opagust's suggestion) - Handling of "Staff Labels" corrected (trimming of " did the job)
Thanks for checking. Blanks do work e.g. for title and other properties. It seems that there is a problem (mine, or NWC's??) just with the StaffLabels enum value ... maybe it has something to do with the fact that it's an enum! (I declared it as text ...).
local staffName = staff.AddStaff.Opts.Name.Text if staffname == nil then staffname = staff.AddStaff.Opts.Name
Thanks! (maybe I use local staffName = staff.AddStaff.Opts.Name.Text or staff.AddStaff.Opts.Name ...).This nested Text objects baffled me anyway, but it is there in my 2.75a.2
I don't mean to throw cold water on this, but why not just save the modified score under a different name? NWC scores only take up a teeny-tiny percentage of space on a hard drive. I do this for parts all the time.
Well, we all probably have our own processes. I compose and arrange directly in NWC; one day or the other, I think I'm done. I let it lie around a day or two, then go over it - and will modify some stretches. But then (or a day later), I create the PDFs (e.g. full score, choral part, maybe a piano reduction) because I am done! ...
... I thought: Certainly, I now find a number of nuisances (typically, overlapping symbols; not nicely aligned hairpins; lyrics too near or too far from notes; lyrics that deserve redistribution to syllables; ...) that need to be beautified. I do this, then it goes to our choir's conductress ...
... who will tell me which parts she'd like to have adjusted (too high, too low, too fast, too slow, too hard, oh no!). So there's a next group of small changes. And as songs often contain equal segments at various places (e.g. motifs, but also complete verses), the changes need to be done at more than one place; so of course, I overlook some of these places, and have to make another tiny change the other day.
On the whole, I'd say that I create about 10 PDF versions up to the final version (which, alas, often still has a few hiccups).
Why don't I "just wait" till the end? I don't really know - but there are probably two reasons: a) I actually do think that I'm done when I'm not. Overlooking some missing symbols and a few typesetting issues is so easy. b) I like to create PDF scores, and even print them, and look at them. It is quite satisfying to see one's own creation as if it were real, published music .
So maybe I rush the whole thing, at places, and thus have to repeat it more often than strictly necessary. And then I complain, and then I program ...
And here is my first discussion posting. I have three questions, as of now:
a) Do the names "PrintConfiguration" and "PrintVariation" make sense? I had called them "ScoreConfig" and "ScoreConditional" first, but "score" is the whole NWC file, thus I introduced the term "print". For the conditional modifications in staves, "conditional" somehow sounds wrong; but is there a better term than "variation"?
b) Is the handling - using "Save" and "Apply" - ok? Actually, this is not really easy: If one forgets to "apply" previously saved settings before changing options or adding additional variations, one can end up with a chaos of options. For the moment, the last PrintConfiguration object shows a diagonal "Active" text in edit mode so that one can see which configuration was apllied or saved last. Is this good enough? I will add multi-print configurations to some of my small (organ + trumpet) and also larger (choir + soloists + string quartet + piano reduction) scores and check how happy I myself feel with this machinery.... c) "Staff Labels" does not work. Even when I manually tweak a .nwctxt file, this options is not correctly written into the PgSetup. I suspect this has to do with the blank in "First System", "All Systems" etc., therefore only "None" works. Is this true? and if so, how can I set the StaffLabels slot correctly with a user tool?? Solved.
Here are three typical examples using PrintConfiguration.hmm and PrintVariation.hmm objects:
PrintConfigurationExample.nwctxt is a simple example which only changes global properties of the score for two prints "1 Full Score" and "2 Trumpet" (I used digits here instead of letters; letters are better as they easily allow for ordering 26 prints).
Typically, one would print as follows:
Apply and print configuration 1: start user tool "Apply", type "1" and "Enter", save and print,
then apply and print configuration 2: "Apply", "2", "Enter", save and print,
finally apply print configuration 1 once more and save - you want to see the full score when you open the NWC file next time.
SinglePrintVariationExample.nwctxt shows, in addition, two typical uses of PrintVariation.hmm:
In measures 5 a text is shown just in the "Trumpet" print. Here, the fun text "Attention !" is inserted before the trumpet begins anew. To "remove" the text in the "Full Score", it is replaced with an invisible grace rest - removal is not possible for single items (but see MeasurePrintVariationExample below). Note that the PrintVariation.hmm is placed after the item - the reason is explained next:
In measure 6, a spacer is modified depending on the print configuration. The behaviour of spacers is the reason that a PrintVariation.hmm object must be placed after the item to be modifed: A spacer would not work when preceded by a user object, as this user object is then between the note and the spacer, which kills its effect on the note.
Finally, MeasurePrintVariationExample.nwctxt shows how to insert a full measure of cue notes in the "Trumpet" print. They replace the single whole rest in the "Full Score". For consistency, also here the PrintVariation.hmm object is placed after the items to be replaced - typically at the end of a measure.
The PrintConfiguration.hmm object supports the creation of differentprints from a single score. The idea is that for each print, such an object stores all the necessary specific options. Two user tools "Save" and "Apply" are used
to save the current options (which are set up as always - by fiddling with them until the print looks right) into the object as strings;
and to apply the options stored in such an object to the score.
Conceptually, each print configuration is placed on a specific staff; this is intuitive for typical "voice prints". Therefore, at most one such object on a staff makes sense - all latter ones are ignored.
The score properties saved by a PrintConfiguration are:
Title, Author, Lyricist, Copyright1 (but not Copyright2; this is useful for information that you want to change on all prints, like a print date);
visible staves (identified by their internal name; if there is a dash, i.e. /, in the name, the identification starts at the dash. This helps with renaming, see this explanation farther down);
master StaffSize and the sizes of all 12 fonts (but not their names etc.);
the 4 margin sizes and the MarginsMirrored checkbox.
In addition to the PrintConfiguration.hmm object, there is a PrintVariation.hmm object which allows to modify segments of a staff arbitrarily(!) for different prints. Typical examples are:
add/modify spacers for a print;
addition of cue notes;
enable/disable various objects, e.g. BarNumber.hmm objects on lower staves.
Some hints for usage: Typically, you would set the following values for different prints ("voices"):
Of course, the staves to be printed;
but typically also a different staff size is needed;
as well as a specific title that indicates the print's purpose;
and e.g. a different print preparation date (e.g. in a copyright or lyricist field);
then, adjusted margins to maybe save an almost empty page at the end.
For multi-line prints (like the director's score or a piano score), I always use a separate top staff (with just one line and many invisible rests, layered with the next). There, I can add margins and user controls (e.g. PgTxt) and system breaks at will.
For single-staff prints, I put the PrintConfiguration on that staff; and use "Top Staff Only" Visibility settings to enable boundary settings and User Controls (e.g. a BarCounter).
In more complex cases, one might add PrintVariation objects for cue notes in some (but not all) of the prints ;
and even more intricate changes like specific spacers or differently aligned dynamics and texts (but this is very hard work to make it work correctly).
It may make sense to add a print sequence number or letter in the staff names, e.g. "A Full Score", "B 1st Violin", "C 2nd Violin" etc. This documents the print order; and also helps to easily select the print configuration in the user tools from the keyboard by simply typing A or B or C etc.
For examples, see next posting.
V.0.3: - Corrected access to bool properties; - PrintVariation.hmm modifies previous objects so that it is useful for spacers. V.0.4: - Corrected label in PrintVariation.hmm for V.0.3 change. V.0.5: - Allows limited change of staff names, by using only name part after / (if there is one) for selecting visible staves. V.0.6: - Copyright2 is no longer part of a PrintConfiguration; see explanation in posting #16 below. V.0.7: - Font sizes are stored!
I assume "soundfonts" also includes "VSTi" instruments.
I use: a) "Sonatina Symphonic Orchestra" for most everything instrumental, also piano. b) "Soundiron Olympus Micro Choir" VSTi in Kontakt 5 player for choral sounds. c) Chorium.sf2 as a standard soundfont for "internal use", I think I also used it for a few brass instruments a few years ago - but I'm not uptodate here.
I overlayed your Ghost.mp3 with a MIDI recording of the NWC file - the Reaper result can be seen in the attachment: This is really very weird: The ghost f# occurs "somewhere in" the 6th beat! (I hope the tempo maps are actually the same; but why shouldn't they be?) ... scratching my head slowly...
One possible effect is that if some notes in a chord fade out faster than others, we (or at least I) at times seems to "hear" the slower-fading notes anew. I do many arrangements for crank organs, where I use "Ocarina" of the Chorium soundfont as a sound that is very near to that of smaller crank organs - and I have had such effects at times, which made me search for spurious notes that simply were not there. (In one of my first arrangements, I found out that at least on faster scales, you can trick the ear into "hearing" notes that are definitely missing ... we seem to just "know" what "should be heard", and then hear it ...). This is not a definitive explanation, but I am not totally surprised about this.
This has now, in a very short time, become a standard tool that I use heavily with IMSLP scores (and, recently, paper scores I got from my trumpetist): The chain Audiveris -> Musescore -> MXML2NWC typically delivers enough pieces of a scanned score to NWC that the result is useful.
- Audiveris often delivers very patchy and weird results; but still, complete melody and bass lines can often be extracted from the result (sometimes assembling them from two or three staves) to save a fair lot of typing time. - The intermediate Musescore step (open MXL, save it anew) usually roughens out a few problems that Audiveris has with MXL files. - I usually start with a new NWC file from scratch, put the MXML2NWC-created NWCTXT in a second window, "tile" both - and copy-pasting starts.
...Or: Audiveris incorrectly read the position. (In part 'P2', measure number "0", I found a normal 'F,4' clef)... So maybe I could change my program to ignore the line number (except for the 'C' clefs) and print a warning if the line number differs from the 'normal' one?
Audiveris definitely finds clefs - especially bass clefs - at astonishing places, e.g. if an eighth flag has a few pixels missing or so. So it would, in my opinion, be the best thing to simply ignore such "impossible clefs".
A great tool - very helpful right now for getting (parts of) PDFs via Audiveris to NWC, for my crank organ arrangements.
I have another problematic MXL file; Audiveris already stumbles on many things in the score, creates a "corrupted" MXL, which I could load into MuseScore and then "beautify" a little. However MXML2NWC then exits with an exception ... I have attached the error message and the MXL file - hopefully you can see what the problem is!
All this looks good. One more thing would be nice: A checkbox that suppresses custom note velocities on dynamics - I might want to use NWC's standard values. I'll now try to "conduct" (add agogics, volume, velocity, tempo, ornaments, ...) to the four symphony movements = this has not much to do with MXML2NWC. After that, I'll try the process with another symphony - I have three or four more scans lying around here!
I'm not THAT sure that this simplicity doesn't contain some fair amount of sarcasm ... but anyway, nice you did it! (Others will find this helpful, I assume).
Just a short "still working on it" message: I'm right now converting scans of modern prints of the 4 movements of a Kospoth symphony (2 oboes, 2 horns, strings) to NWC.
My process will require two passes through the NWC score: The first one makes all the notes and measure lengths correct - i.e., all notes are where they belong; the second is the fine-tuning process. I'm right now in the first pass, where I learn that Audiveris sometimes ignores (or despairs on) complete pages; first, I rewrote such missing segments manually - but now, I let Audiveris do another scan of that single pages - it comes out roughly right, so that after running it through MXML2NWC, I can paste in the respective segments (what is sorely missing for this from NWC, is vertical - mutli-staff - marking and copy/paste).
Right now I work with a single screen, but this is somewhat tedious. Tomorrow, I'll try two screens - one for the source PDF, the other for NWC.
Re selecting/deselecting item types, right now "Global Modification (adp)" with DELETE is sufficient; at one point I also did a F3-Del-Sequence. What might be helpful, is a switch to remove the "System Break" marks from bar lines - the NWC score will definitely be laid out differently.
On Windows, when the sound pipeline does not work, I look a the byte counter of my virtual MIDI cable - this helps me to understand whether the problem is before the cable (NWC, i.e. MIDI generation) or after (my DWS, e.g. Reaper):
When I play a piece and the counter increases -> MIDI commands are sent out, problem is at receiving end.
No counter increase -> NWC is silent (muted staff, ...).
Maybe this is also possible on Linux. I have no idea about Linux, but here are two links that seem to give reasonable information that might be helpüful:
Great - all items fine (especially, reopening the converter for more files is really no problem).
So, I now try to use the results to create a useful score. My initial experience with the "Go, tell it" score is: Not a nice job. The voices are not separated as one would hope - sometimes two-voice chords in a staff, but a few notes spill into another staff; long slurs and cresc/decresc, with many haphazard texts in between; and at times there are missing notes or dots, leading to too short measures.
It might be that a more useful process is actually: Remove everything except notes and rests (probably with a user tool), create a correct "naked score" from these; and finally add all the "small things" (and not so small ones) - either manually or, at a few places, by copying something over from the "ORM-ed" score.
The whole enterprise is certainly not for the faint-hearted, at least with this Audiveris+Converter pipeline; where the main "problem", but also "heavy-weight-lifter" is Audiveris: What it can and cannot do essentially defines the result. So be it. I'll see what I learn ...
... I wonder if any of these things are doable without the developer but as plug ins or objects? ...
I went through the lists in their current state and tried to imagine whether a plugin could be written to do this. On the whole, the answer is a (more or less) sound "no" (unless I have overlooked something intricate).
There is another question: All the large score editors (and competing smaller programs like Capella in Germany) are now "score environments", with many extensive functions - at least for large scores (multiple movements, prints for various musicians), but up to and including scanning and sound production. It seems to me that many of the advanced functions are bought from small specialty shops, which requires a "company strategy" on how the environment is to evolve. I cannot see that NWC, both from its concept and its manpower, will ever be able to do this.
The only way I can see for NWC to compete is to open up even more, maybe to the point of open-sourcing it, but at least to the point of providing an API to call all actions and modify a score temporarily extensively; so that a few hackers like Mike or me could write "tools around NWC": Where NWC is then only a component of a larger system that controls e.g. scan programs like Audiveris, multi-movement scores (probably via ZIP files with name conventions or meta information), print runs which "tickle" various score elements (font sizes, spacers, system breaks, upper and lower staff sizes, margins) to create different print outputs and the like. This would be a next (final?) step of "community enabling" (which started with tool and Lua integration), which might carry NWC into another decade or so ...
Kospoth's symphony worked nicely* for the 1st, 2nd and 3rd movement. The mxls produced by Audiveris already have a fair share of problems (however, some are from untypical notations in the score), but the result is quite usable. However, the 4th movement stumps MXML2NWC 1.0.2 (I hope - I just installed it over the previous one; does the installer replace it? ... it would be nice if there were a version info somewhere), with another Python error. The zipped .mxls are in the attachment (however, due to renaming, the XMLs stored inside the mxls do have strange names from my scanning operation - I hope this is fine).
* However, there are a few things where I stumble a) The first staff of each NWCTXT contains "a million" PgTxts at the start (see NWCTXT result of second movement in the attachment). b) When opening, the files require a font "Default" which I apparently don't have. c) Opening another .mxl file often (always?) crashes MXML2NWC later. You can try it with the symphony: First, convert and save movement 1; then, press "SELECT ..." again and open movement 3. "CONVERT" will result in an error - see attachment.
a) I just scanned a modern transcription of a four-movement symphony of the obscure German composer Otto Carl Erdmann Duke of Kospoth (1753-1817). His great-great-great-nephew or something lives in our town, and for a birthday of the old gentleman I'll play a piano reduction I wrote ... but I'd also like to have the symphony played with some nice soundfonts (I'll try Sonatina Orchestra), and for this, I need the whole score. Instead of writing it, I'll try Audiveris + MXML2NWC! I'll write a separate reply for this.
b) In the attachment are (in a single .zip) two more .mxl files produced by Audiveris. The input for this was a scan of Ruth Elaine Schram's arrangement of "Go, Tell It On The Mountain" (see http://www.hmmueller.de/Scans/RuthSchram_GoTellItOnTheMountain.pdf - "permanently out of print", according to the publisher). I'd like to create a rehearsal voice/mp3 for a soloist singer from this via NWC. Audiveris produces two "movements", where the latter is the separate coda starting on the last page but one. Giving the first file to MXML2NWC 1.0.2 unfortunately creates another Python stacktrace ... Maybe you could look into this.
A much more brutal experiment: I found an open source OMR ("optical music recognition") program called Audiveris on GitHub. I took a somewhat complicated score - it is a modified version of John Rutter's "Dormi Jesu", which we currently rehearse in our choir, which I have written with NWC (we had to change a few things, because of SSAB, and because ... well ...) ---> see attachment "20210922-ch+p.Rutter_DormiJesu.pdf".
Audiveris creates .omr files. In this case, the resulting OMR file has about 1,5 MB (also when zipped - seems to be some image file format), so I couldn't append it here.
Audiveris can export to MusicXML, so this is what I did. The result is a .mxl file, which is a zipped XML file ---> see attachment "20210922-ch+p.Rutter_DormiJesu.mxl.zip" - I zipped the MXL, because the forum does not accept .mxl files. Opening the .mxl with MXML2NWC does not work - it seems that it does not see that this is a zipped file which needs unzipping (and yes, MXML2NWC does not accept .mxl as a standard extension for files it wants to open, so this is an "advertised feature"). Still, I have the (small) feature request that .mxl files are accepted, i.e. unzipped and then worked on the XML.
Manual unzipping of the .mxl yielded an XML file, which MXML2NWC actually digested, with a host of messages which I ignored (and did not read; and maybe would not have understood). Still, it created an NWCTXT file which is actually "usable" in the sense that one can extract substantial parts from it in NWC (which is the whole idea of OMR).
I also opened the .mxl file coming out of Audiveris in Musescore. Musescore complained that this was not a valid MusicXML file, but after pressing "Ignore" it also gobbled it up and created a score, which I again exported as MusicXML ---> see "20210922-ch+p.Rutter_DormiJesu_ReexportedFromMusescore.mxl.zip. Once more, I had to manually unpack the .mxl. Now, when I gave this to MXML2NWC, it ran into some Pythonian error.
I daresay I would be interested that this process works - even if with problems and lost information and whatever ... it might help me to create more musical renderings from scores lying around. Is there any possibility to improve, a little, on the problems above?
First of all, thanks! - and wow!!! - this is and will be really, really helpful for me: In Germany, laymen's scores are mostly written in Capella. Being able to get them into NWC is great (even though there's some work to be done afterwards to clean up, of course - depending on the quality I want to get).
There's one thing that I would think about: The installer is not signed, and so it complains about an "unknown publisher". I feel that I would not recommend this program to anyone with the advice "just click on advanced and install anyway" (even though I did this, of course). A "right" solution is of course to purchase a code-signing certificate (quick googling found $83/year, less if purchased over 3 years, at https://cheapsslsecurity.com); but I've never done this, and the process (identity verification) might be a hassle? Publishing the Python script and a starter .cmd/-bat file, with additional instructions on how to install Python might be another, and simpler, way to go ...
Last, the 1.0 version is now quite useless on the website, isn't it?
I tried to convert a file from Capella 7 to MusicXml and then to NWC. Unfortunately, there's some hiccup - is this the right place to ask? I have added the XML file (as a zip) as well as the error I encounter ...