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 (https://forum.noteworthycomposer.com/?topic=10129.msg73645#msg73645));
- master StaffSize and the sizes of all 12 fonts (but not their names etc.);
- page options: JustifyVertically, PrintSystemSeparatorMark, ExtendLastSystem, DurationPadding, PageNumbers, PrintStaffLabels, ShowBarNumbers;
- 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!
H.M.
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.
H.M.
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??
Thanks for help and comments!
H.M.
No, for sure it doesn't depends on the blank.
I did this way with no problem:
Item = nwcItem.new("|AddStaff");
Item:Provide("Name","Perc. staff ".tostring(HighestPercStaffNumber))
Item:Provide("Group","Percussions")
Item:Provide("Label","Wood Blocks")
table.insert(MidiStaves[StaffCount],Item)
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, let's say that there is an error in one of the staves that needs to be corrected, and that staff is present in several of the different configurations. The composer would need to make the change to each of the saved score copies. Whereas with
@hmmueller's approach, only a single score would need to be updated.
I haven't yet experimented with the new objects, but I think I see how they might be very useful.
Hi Heinrich,
I got this error when I ran the user tool:
When I removed the '.Text' at the end of line 142, the error didn't occur any more.
But I think it has to do with the version of nwc (mine is 2.8 beta 1).
So maybe this is the best solution:
local staffName = staff.AddStaff.Opts.Name.Text
if staffname == nil then staffname = staff.AddStaff.Opts.Name
That works for me.
Thanks, Mike. Hadn't thought of this angle.
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 ...
H.M.
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
H.M.
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 ...).
I'll play around ...
H.M.
That seems a bit neater. It's been a while since I last programmed in lua, I'm in love with Python now, but that's the way I would write in Python too.
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)
H.M.
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.
Label for "complete measure replacements" in PrintVariation.hmm was still wrong - corrected in V.0.4.
H.M.
I have uploaded version 0.5. With it, it is possible to change the name of a staff from e.g. "soprano" to "voices/soprano" without having to update all PrintConfigurations - the identifying name for a PrintConfiguration is what comes after the (first) /.
This is useful if one wants to add a PrintConfiguration to an existing staff; and then rename the staff so that the name shown in the Apply and Save user tools indicates the PrintConfiguration.
Example: Assume there are staves R.H. and L.H. in a piece with other instruments, you might want to put the PrintConfiguration for the piano part on the R.H. staff. But now, you'd like to rename the staff so that it shows up in the Apply/Save tools as "Piano part".
Solution: Rename the R.H. part to "Piano part/R.H." - this is the name that will be seen in the tools, but still, any PrintConfigurations referencing the staff as "R.H." (e.g. a complete score) will find the staff.
Of course, if one consistently uses a "top control staff" for each part print, this is not necessary - but doing so for smaller parts has also its (complexity) problems ...
H.M.
This object has, for me, certainly proven its value. As a recent example, I have written a full score (4 voices, 5 strings) of Durante's Magnificat in B flat, with its 6 parts, as we needed a number of changes for our choir and strings: SATB > SSAB, rewriting a TB piece as SB, replacing a viola with a second violoncello (so it goes, in real life ... viola players are hard to get around Christmas), with all the consequences - changing clefs, moving notes and lyrics lines to other voices, rewriting a host of measures for range reasons or for better voice leading.
These changes evolve in a "development process" in many exchanges with our conductress, which takes 6 or 8 rounds: After maybe the first 3, the instruments are stable, but the singers' voices (choir and soloists) get more fine-tuning afterwards. And of course, in that process, it is expected (and I expect) that I can produce a
consistent set of
- conductor's score
- choir/singers' score
- new cello voice
- (but, int his case, no other strings and general bass is needed, as we can use bought scores there).
with a reasonable layout - readable, not too many pages, and of course no errors and acceptable formatting - with no manual checking, and a minimal amount of headache.
For this to work, my typical score consists of
- a top "full score" staff with a PrintConfiguration, which is layered with the first notes staff (typically soprano); it contains the necessary line/page breaks for the full conductor's staff and elements only for the conductor;
- another PrintConfiguration "choir" staff with a single line that is layered with the first notes staff (typically soprano), with breaks etc. for the singers;
- the singers' staves; which will only be printed as part of a full or choir score, thus without PrintConfiguration of their own);
- the strings' staves; which will be printed in a full score; and on their own (e.g. in a larger font and with different line breaks), thus they have their own PrintConfiguration objects.
However, there is one feature that had to be changed: Up to version 0.5,
all score properties (title, author, ..., and also
both copyright lines) were saved per print configuration ("score"). With the evolutionary process outlined above, it was necessary to mark each version very clearly - for that, I chose the second copyright line (Copyright2) for placing a "version date" on each page. But keeping these dates consistent over multiple print configurations was very error-prone. Thus, starting with version 0.6 Copyright2 is no longer touched by the PrintConfiguration objects and tools, and thus a Copyright2 value is consistently shown in all printed scores (until it is changed in NWC directly, of course).
This is a breaking change ... but I think that no one out there uses this object as heavily as I - or even at all ;)
H.M.
There was a significant bug (or, rather, omission) in this object: It did not save font sizes. I always thought it did, but ... hm. But from version 0.7 onwards, it does. Also, the online documentation now spells out precisely what is saved.
H.M.