I've attached version 5 to the first post in this topic.
I was not able to use the "@" for the include, as I think that it does not help at all (it certainly did not prevent the nwc error handler from kicking in just the same to display the warning!), and I think it can do harm (suppressing errors within the include file itself so the user does not know why his changes aren't taking effect!). I simply added a file_exists check before doing a require_once, to get the best of both worlds.
I've added some code to initialized the replace text to "null", and only set it to an empty string once the user clicks "ok" in the "replace" window. In this way, it won't do a "replacing delete" until the user has "confirmed" that that's what he really wants to do. You'll notice that a "replace next" brings up the prompt, even if find text was previously entered, so the replace text can be confirmed.
I've added keyword sets for all the field names (in addition to the prior object types) for file properties, staff properties, staff lyrics, and staff notations. There are several cases where a field name can be used for very different object types, and without an nwc lexer, the code cannot tell the difference and highlight accordingly. (See the comments in getKeywordList for details.) I have not yet tried to enter all the "enumerated" field values yet.
I agree with Richard - layering is the way to go, for maximum flexibility. I frequently enter SATB hymns as 4 different staffs, with the first staff (Soprano) layering onto the second (Alto) for Treble clef, and the third staff (Tenor) layering onto the last staff (Bass) for Bass clef. Any two (or more) parts sharing a common clef and key signature can be layered together, for any number of "voices" on a layered staff!
When entering the parts, you may frequently have to do any of the following to notes (so that they look good when layered):
Force stem up (typically in the "upper" layer) or down (typically in the "lower" layer).
Override stem length, to get eighth note (or shorter) flags/beams to exactly overlay.
Add extra note space to make close-together notes split apart a bit.
Add extra accidental space to make close-together accidentals split apart a bit.
Force slur upward (typically in the "upper" layer) or downward (typically in the "lower" layer).
Force tie upward (typically in the "upper" layer) or downward (typically in the "lower" layer).
Set "articulations on stem" to move articulations away from the other layer's note.
You may also have to tweak the vertical offset of some rests, to move them away from the other layer's note (or rest). You should never have a Chord or a Rest-Chord with this method (except perhaps if a single part divides into two for a bit I guess)! I'd like to write a script someday to automatically make the above changes, but they have to be done manually as needed for now.
Your "master" copy will always have each part in a different (unlayered) staff - when you print, the layering will automatically kick in for you. If you ever want to print out any one individual part, I recommend you try the script I use for this. It simply removes any possible setting that you may have forced above, letting NWC revert to its default. Make sure you revert back to your master without saving, once you run this script and print the results!!
[The script runs on a "clip", not a "file". The clip is usually an entire staff. You can easily run the script on more than one staff via my "Run User Tool" script.]
By the way, I often force all stem directions, even when the default is what I want. This helps preserve proper layering if you ever transpose and/or change clef!
Sorry I'm not so bright, William - I didn't consider adding extra hidden rests to each affected note (probably because that reduces the note-on time from what it should be for those notes). It is simpler than what I was thinking, which was to either add a tied note to each note to truly extend the note (but then you can't hide the tie), or to change the note itself to extend it (but then you can't hide the dot e.g.). If one can live with shortening the notes, and one does not have too many other staffs to change, I can see the tempo and time signature change being good now. Thanks for the example! (Sorry you didn't like my layering example - I think layering is very handy and I use it quite often - I just wish one could layer a particular measure, without having to layer all other measures up to that point, for spacing)
If one wants to avoid all the tempo and time signature compenstaion across all staffs, I've attached my best attempt at a single-staff audio/video solution to William's example, and my best attempt at a layered staff solution. Neither are great, but the layered solution isn't so bad IMHO (note that it requires all staffs to add some extra note space to the third beat).
Edit - I'd attached nwctxt files instead of nwc, assuming this would be more compatible with 2.1 (over my 2.5). I think now I was wrong, and I've removed the Locale and Editor lines to (hopefully) be compatible this time.
The tempo change is ingenious, and it gets exact results. But I can see it being intimidating to use, primarily since it seems to necessitate changing all other staffs to compensate.
You may find it easy to calculate the required tempo and time signature changes for the primary staff (it makes my brain hurt :-), but is it so easy to make compensatory changes to all the other staffs?!
I've also taken a look at the MIDI file generated by your solution. To my limited understanding of MIDI, the tempo change does not seem to make it into the file, and playback outside of NWC will be incorrect?!
I'd purposely used "include_once" instead of "require_once", specifically because the include will not fail on file not found, when the require will. Or so I thought. Technically speaking, PHP will emit a warning if the include fails, instead of the fatal error caused by a require failing. The warning would go unnoticed by default, but nwc2clips.inc sets an error handler that makes it visible. I should have tested the no-file situation instead of assuming that I had it covered!
I went back and forth on the replace allowing an empty replacement string. I ended up leaving it out, since it simplified the code greatly, and it could still be done (as you say) with F3/Delete pairs. I will revisit this, and see if I can get the code in there again, without undue complexity this time. I wanted to wait and see if anyone noticed this, and wanted such "bulk" deleting.
I am going to fix these shortly, and also add more keywords to the default set - I think I want every possible keyword added, in the extreme. I'd then have to update the script for any future NWCTXT extensions, but when typing in new NWCTXT, it's nice to have the "confirmation" that you've typed it right, by seeing the color turn on. One annoyance is that "4th" through "64th" register as "numbers" even if a keyword is added for them.
I can't do "folding" or syntax error highlighting until NWC's wxWidgets supports a few more methods, and I can write my own lexer.
Hi Rick - I think you'll be more comfortable with the V4 script attached above. I've removed all but one of the error checks, and I've pulled some code out into functions, so a couple of places look much simpler now.
I've also added a "nwctxt.colors.php" file - I'm thinking we all should override with our personal preferences there, so that any new version of the tool does not overwrite them.
I'm likely being overconfident, but I consider this script to be beyond "alpha", and even beyond "beta" - I consider it done! I will of course fix any bugs found, and I'd love to hear opinions on a default color schema. But it isn't that complex of a script to expect major problems!
I actually planned on leaving the defensive code in! I think it adds no measurable realtime to the execution, and I have a faint idea that I may allow some sort of "import" in the future. (Say for example that one wants to pull in a "quintuplet" template from a canned file. :-) I'd want to do a bit more verification of nwctxt from a file, as opposed to from NWC.
Of course, the above assumes this is for a hidden audio solution, with any visible muted solution layered on. If one wants an audio solution that can also serve as the visible solution, and one can live with some mangling of note start and note on times, the eighth notes are superior. Some sort of text bracket and a "5" are all that is needed! The eighth note version with identical rest chords is below (not sure though if moving the "odd" rest here helps the mangling or makes it worse).
Very ingenious to make use of rest chords here! It allows (untied) rests to get the note-start timing correct, and independently, it allows single notes to get the (uniform) note-on length correct. I like it a lot.
Some minor improvements though. Mainly, you can't use an eighth note for the note-on length here, since it is trying to simulate 4/5ths of an eighth note! The note-on alone would practically exceed the total note on+off time we want. I've changed the notes to dotted sixteenths, which seems to give the best note on/off ratio (combinations of double-dotting/staccato/tenuto didn't do any better). I've also swapped the order of the rest pairs, so the smaller rest is in the rest chord, and split the last rest in half. This allows all the rest chords (including the "odd" one) to be identical, so one can be created and copied to all the others. Finally, I've moved the "odd" rest from the end of the group to the middle, so each note start is as close as possible to its intended time.
Colorizing is available now! New version 3 is attached to first message in this topic.
Lines 15-40 of the script were added, and allow a user to highly customize his colors quite easily. It is more flexible than you might think, but less flexible than you might dream. :-) The very basic color scheme I have in the script right now is best seen editing an entire file, rather than a small clip.
The current NWC wxWidgets DLL did not support several critical methods that would have been required to write my own lexer. So I borrowed the best one already available, which interestingly turned out to be one for assembler code!
Someday, I'd like to implement "code folding". This would allow say an entire staff or measure to be collapsed down to a single line when not working in that area. It could be expanded as needed, and would be "auto-expanded" upon saving back to NWC. I am used to this when viewing Music XML files, and it's quite handy.
I think I covered that solution in Staff-1 of my examples! It's just scaled down from quarters to 8ths, and I'd mentioned that that staff could be scaled down to 8ths, or 16ths. It does however show me that I should have simplified the last of the 5 groups in my Staff-1, from two tied dotted 16ths to just the one dotted 8th! (Although you added a tenuto to the last note, to perhaps give it some of the length that it lacks over the other 4 notes - but it can't stop the next measure from starting "prematurely"?)
And I agree with Rick, that for NWC, 192 is definitely the natural unit for quarter notes. In other words, 12 is the natural unit for the smallest possible note. (To properly handle double-dots, it must be a multiple of 4, and to properly handle triplets, it must be a multiple of 3.) Since NWC only goes down to 64ths, 192 is the quarter unit, but Music XML goes down to 256ths, so 768 is the quarter unit there! (Although Music XML has a "divisions" value, to divide down the units on-the-fly, when so much granularity is unneeded, allowing smaller magnitudes - but NWC has no such "divider".)
Strictly speaking just about hidden notes that serve only to produce audio playback of quintuplets:
The tempo change is ingenious, and it gets exact results. But I can see it being intimidating to use, primarily since it seems to necessitate changing all other staffs to compensate. For 5 equal notes played in the time of 4 quarter notes, alternating between dotted-eighth and double-dotted-eighth is also ingenious, as it is quite simple to implement.
If one wants more exact playback there are other options. Say that a quarter note is a duration of 192. Then the ideal duration of each of the 5 quintuplet notes is 153.6, which of course is impossible in NWC. The workaround above gives 3 notes of 144 and 2 notes of 168, for the correct total of 768. There are other combinations, of various complexity, which brings down the standard deviation, while keeping the total exact.
In the attachment, Staff-1 shows perhaps the simplest improvement, yielding 4 notes of 156 and 1 note of 144. The best approximation is in Staff-6 and Staff-7, yielding 3 notes of 154 and 2 notes of 153. The simplest solution, in Staff-0, uses no smaller than eighth notes, so it can be scaled down all the way to 5 notes in the time of 4 32nd notes. Many of my solutions cannot be scaled down at all, since they involve 64th notes.
Recommendations, in increasing order of complexity and exactness:
Staff-0: single note per quintuplet note, scales down to 32nd notes only.
Staff-1: two tied notes per quintuplet note, scales down to 16th notes only.
Staff-5: three tied notes per quintuplet note, scales down to 8th notes only.
Staff-6,7: three tied notes per quintuplet note, does not scale down past quarter notes.
If all someone wants to do is turn an ABC file directly into MIDI and/or sheet music, I see no advantage to interposing NWC. There is only a potential advantage if they want to make changes to the music prior to turning it into MIDI and/or sheet music. Do you also provide for NWCTXT to ABC conversion, so they could capture any edited changes back into an ABC file? This would help them be able to update their ABC files, while continuing to use the tools they're used to for generating MIDI and/or sheet music. Would you be at all interested in letting me work with you to create a user tool to provide easy import/export of ABC into/from NWC?
Invocation is just as for nwsw nwctxt file/clip explorer, but perhaps not everyone has that by default?! I have it under Developer Tools, and I don't think I added it myself - it's one of the new "locked-down" built-in tools I think. It's really easy to add the editor, if you just copy and tweak the corresponding explorer entry!
I think if input is not compressed (which I obviously did not test, and should have), the text is perhaps padded out to a full block (with null chars), and that makes it appear like there's more text after reading the last nwctxt line. PHP's feof still returns false after reading the last nwctxt line, as there are more physical chars left, but fgets then returns an empty string (after tossing the null chars). I agree that NWC2ClassifyLine might have handled this more gracefully (and it may well have in the past, but was lost in a speed optimization), but I've added a precheck to toss empty lines before calling it. With the zlib decompression filter turned on, reading the true last line chews through all physical chars, and the feof is immediately detected.
In addition to adding the precheck for an empty string (line 30), I've added a SetMarginWidth call to get rid of the default left-side margin (line 204).
I think several of us sometimes select objects in NWC and copy and paste them into an editor (like Notepad), so we can change the nwctxt and copy and paste them back. For example, this can be really handy to change individual notes within a chord, to change a position and/or to add/change/delete accidentals, ties, noteheads, colors, etc.
Borrowing heavily on nwsw_SimpleEditor.wxphp and on nwsw_nwctxtFileExplorer.wxphp, I have created a simple editor designed to edit nwctxt (clip or file). The editor automatically removes the header and footer, and any comments (file), and any fake/context items (clip), and presents the selected objects in a WYSIWYG editor.
Within the editor, the standard copy/cut/paste actions are available, as well as undo/redo. There are find and find-next actions, and also replace and replace-next. A select-all is there, but you shouldn't need it, as all of the text is automatically passed back to NWC upon exit. I don't currently see any need for new/open/save.
I am looking into adding an "nwctxt lexer", to add some color to the nwctxt. This can make it easier to read, and to spot syntax errors in your changes, before exiting back to NWC with them. I will wait to see if there is any interest in this editor, before putting any more than today's work into it.
Invoking the editor is just like invoking the existing explorer. Create one shortcut for "clip" mode and another for "file" mode. Simply copy the existing explorer entries and tweak them, to create the new editor entries. (Btw, the new copy command in the user tools box is a good way to see built-in command info, since you can't edit them any more.)
The "file" mode for this editor could be particularly handy I think, to edit song and staff header information. I don't know of any other way to cut and paste file nwctxt to an editor, so making such changes to file nwctxt previously involved saving the file and later reloading it (or exporting and reimporting), which probably was never worth doing previously.
HTH, Randy
P.S. Conventionally, you should rename the ".v#.php" script to be ".wxphp", but it should work as ".php" too - the forum allows a "php" extension but not a "wxphp" one.
[red]Edit: Sorry - I see now that Rick embedded this knowledge in his example![/red]
If it helps you any, your program can emit multiple SongInfo lines, and NWC will "merge" their values (it's kind of a standard already to break the StaffProperties into two lines, when they could be only one line, or more than two lines). For example:
I am not at all familiar with mxml2nwcc.exe, but I will look into it for you. Ideally, both tools would generate identical output for any possible Music XML input, but this is unlikely, given the complexity of Music XML. [Note that my program is not a standalone compiled program, but is instead an NWC user tool, using NWC's PHP and wxWidgets "API", and designed to simulate "native" support of Music XML import from within NWC itself.] Is there no "nwcc2mxml.exe" analog out there, supporting export of NWC to Music XML?
If you would send me some of your Music XML samples, preferably with their corresponding original PDF scans, I would be much obliged!
If you use both another notation program (which supports Music XML) and NWC, please send me a Music XML version of a favorite song you've created in your other program. If you can send me a PDF version of the same song, it would be even more helpful!
I will use these files only to test my Music XML importer user tool for NWC, and I will send you back the NWCTXT that the tool created for your song. You can then judge for yourself how well Music XML served as an intermediate for Sibelius (etc) to NWC file conversion.
IMHO, you have no chance whatsoever of getting an NWC file format spec. You also have no chance of getting an NWCTXT file format spec, but its text format can be reverse engineered much easier than the binary format.
I am not familiar with XMPlay (or Winamp for that matter). Does it just do audio playback, or does it do visual display as well? If audio only, then why aren't you just using MIDI files, either exported from NWC or generated via NWC-CONV? If visual too, then can XMPlay read another format, like MusicXML or LilyPond or ABC, which NWCTXT can be converted into? I'm guessing it must just be that youwant the convenience of not having to do any special exporting or converting?
This happens to me a lot. In fact, I just noticed that my current NWC instance had the problem right now! When it happens, tooltips still work fine in other apps (e.g. WordPad). Only thing I've found to clear it is to simply close and re-open the NWC instance.
In every piece I can recall, the measure numbers continue incrementing right through *all* special endings. Otherwise, by your logic, do you quit numbering measures from a coda sign through to the D.S. al coda, and resume numbering measures in the coda?! :-)
My interpretation is that measure numbers count "static" measures - every measure is counted linearly straight through the piece, with no regard whatsoever for the "dynamic" playing order.
Also, some folks handle a pickup measure by setting the starting bar number to 0, rather than leaving it set to 1 and exclude the first barline from the count.
A pickup note usually requires a visible single barline after it. If I put the extra hidden double barline after the pickup note (either before or after the single barline), the audit seems to remove the visible single barline? Of course, if one can live with a visible double barline after the pickup note, then this solution requires no extra hidden object(s) at the beginning!
Playing with the ending measure more, I seem to find now that neither of the options above (hidden rests or hidden time signatures) work once the "extend last system" trick is used (where the "ending bar" is set to "open (hidden)" and an explicit "section close" object is added with "force system break"). Does anyone have a solution for this combination?
A problem with audit bar lines occurs when there are pickup notes at the beginning of a piece, and the bar lines are added/changed to wrong positions throughout. (And even with this fixed, when there is an associated shortened measure at the end of the piece, extra unwanted rests are added.)
Rick pointed out the two solutions to this problem here http://my.noteworthysoftware.com/?topic=6119.0, but I thought there might be benefit to spelling them out in a tips and tricks item. The examples below assume the piece is in 4/4 time with a single quarter note pickup, but other combinations can easily be supported in the same way.
Option 1: Prepend invisible rests to pickup notes to pad first measure to full beat count, for example, add 3 hidden quarter rests before a quarter note pickup in 4/4 time. Also optionally append invisible rests to final notes to pad last measure to full beat count, for example, add 1 hidden quarter rest after a dotted half final note in 4/4 time.
Option 2: Surround pickup notes with invisibile time signatures to effect actual beat count, for example, add a hidden 1/4 time signature before a quarter note pickup in 4/4 time, and a hidden 4/4 time signature after it. Also optionally add an invisible time signature at the beginning of the final measure, for example, add a hidden 3/4 time signature before a dotted half final note.
Option 2 is better than option 1 in that it does not delay playback any at the start of the piece (or hold it over any at the end). Option 1 can be better than option 2 in that it can be done in one fewer added hidden item (e.g. use a dotted half rest rather than 3 quarter rests).
Apologies in advance if I am not correct in any of the above, or if this is all already spelled out somewhere else that I did not find.
It seems to me that this tip is for those who want to enter notes via the virtual piano keyboard, but do not want the automatic bar lines to pop up. There does not seem to be a way to directly disable these, so the fake time signature does the trick.
Note that the best time signature to use (i.e. the one that lasts the longest) is 128 over 1 (which allows 512 quarter notes before a bar line pops up).
Of course, hopefully after all notes are entered, one would simply edit the time signature to the correct value, and then audit bar lines to get all the right bar lines added.
If one does not want the automatic bar lines only because they assume 4/4 time (when the piece is otherwise), then one should simply add the right time signature to begin with, and bar lines will pop up exactly as needed in the final piece (except for pick-up note handling, which I'm sure is addressed in another tip :-).
If two layered notes are both the same pitch and the same duration, and they are not whole notes, it is customary to exactly overlay the noteheads, with stems in both directions, as David says. Else if their durations are different, or if the "top" part is not at least two scale steps higher in pitch than the "bottom" part, it is customary to increase note spacing of one of the notes, as Warren says.
Has anyone ever seen two solid noteheads overlaid, where the durations were different (e.g. a quarter over an eighth)? The stems could make this understandable, but I don't think I've seen this done.
One possible use of the new "Run User Tool" tool is to aid in new user tool testing/debugging.
If you run your new clip script via the "RUT" tool, and you check the box to "Display summary of changes, if user tool returns success", then you will see a NWCTXT "delta" of the changes that your script made. The delta for each staff is shown in turn separately. At any point, you can make "backdoor" changes to your script, then do a "back" and a "next" in RUT, and see the new results of your script, all without leaving the RUT environment. Once happy with the changes, you can proceed out of RUT and see your changes applied within NWC2.
The RUT user tool entry to invoke your new user tool could have a command like this: php\php.exe scripts\prw_RunUserTool.wxphp display all "<yourtoolname>"
The display pre-checks the box to display summaries of changes, and the all says to do all staffs in turn. Make sure to set an "Input Type" of "File Text", and check the options "Returns File Text" and "Prompts for User Input".
Sorry about the typos on "giusto" and "senza" - I wrote them both down from my source correctly, but typed them into my forum post incorrectly - can't read my own handwriting.
Of course, my earlier post became irrelevant, once it was revealed that the canceling term was needed only for NWC playback, and no performer would ever see the term. In that case, any NWC performance style (other than the ones that affect playback) would be sufficient, since it would be hidden to the performer.
You may not find this trick useful, but I have had occasion to use "Articulations on Stem" for both layered notes, so then adjusting the stem length of one (or both) of them brings the articulations into alignment upon layering.
After all my years in music, I can't say that I remember seeing a common way of canceling performances styles! I like Rick's "semplice", which means "simple" or "plain". Here are some other possibilities, in no particular order (substitute legato with the performace style being canceled):
senzo legato - without legato
meno legato - less legato
rigoroso - strict
non legato - not legato
niente - nothing
guisto - proper or exact
The only other "canceling" terms I could find were "a tempo" to cancel an accelerando or ritardando, and "loco" to cancel an 8va or 8vb.
Agreed. Within the function, the strpos needs to look up "|$ObjType|" instead of just $ObjType, to keep "Rest" from being spotted within "RestChord".
IMHO, NWC2ClipItemWithPitchPos should initialize $PitchPos to only array(), instead of array("Pos" => array(), "Pos2" => array()). Then one need only code if ($o->PitchPos) to determine if an object has any pitches.
Note that to process pitches, one need not first determine if an object has pitches. The following code works just fine in all cases (any excess processing time for non-pitched objects will not be noticed):
foreach ($clip-Items as $item) { $o = new NWC2ClipItemWithPitchPos($item);
foreach ($o->PitchPos as $npps) { foreach ($npps as $npp) { <operate on $npp> } } }
Of course, to effect any changes to pitches, one currently must not call ReconstructPosOpts without first verifying the object has pitches.
IMHO, ReconstructPosOpts should be replaced by its own ReconstructClipText, which overrides the one in its parent NWC2ClipItem class. The implementation would do the "ReconstructPosOpts" stuff (as needed), and then call its parent ReconstructClipText. Then all objects could be "reconstructed", without regard to whether they are pitched or not, or a pitched item class or not.
Static functions are traditionally called with a "class::function" syntax, instead of the regular "object->function" syntax. It was interesting to me to see that PHP allows the $o->ObjTypeHasPitchPos(...) shorthand, instead of insisting on NWC2ClipItemWithPitchPos::ObjTypeHasPitchPos(...)! But sure enough, from the manual:
Quote
Declaring class properties or methods as static makes them accessible without needing an instantiation of the class. A property declared as static can not be accessed with an instantiated class object (though a static method can).
What is the idea of any script, but to automate a process which would be tedious to manually do otherwise?!
I found myself doing the following 5 separate times for every hymn I entered:
Click on "File", Click on "Print" (or Ctrl-P)
Wait for Print box to come up
Choose "PDFCreator" for printer (if not already there)
Click on "OK"
Wait for PDFCreator window to come up
Click on "Save"
Wait for Save As box to come up
Click on end of File Name
Enter differentiating suffix [" (C)", " (Bb)", " (F)", " (Eb)", or " (C-alto)"]
Click on "Save"
If you find that doing this process so often is easier (or virtually the same) than running a single user tool, you're perfectly welcome to do so! I have no illusions that this script is a great time-saver for everyone - it just works well for me, and I thought I'd share it, just in case. Again, apologies if I'm further wasting anyone's time here.
[Using RunUserTool and other scripts, I am fast getting to the point where a single user tool invocation can automatically generate all 5 of my PDFs for a hymn (for C instrument, Bb instrument, F instrument, Eb instrument, and C instrument alto clef). This PrintToPDF script was a part of that automation process.]
I doubt anyone will have a need for this script, as I did, but thought I'd post it anyway. Apologies in advance if wasting your time. And if someone has a similar script done with "AutoIt" instead of VBScript, I'd be interested in it.
Attached script automates key sequences needed to print current song in NWC to PDF file (song need not be saved to a file). Script was written to expect PDFCreator 0.9.6, but I believe it can easily be modified for other PDF printers if needed. Script allows for an optional command-line option which becomes a differentiating suffix for the PDF file.
Script does "inject" key presses, which I'm not a big fan of, but it has some safeguards. It only does key presses, and never does mouse clicks. It makes every attempt to ensure correct application has focus before injecting key presses. It does nothing to the NWC session (or the original file), but instead spawns a separate NWC Viewer (via a temporary file) to do the printing (script can be greatly simplified if one is comfortable injecting to NWC itself - I was not).
I use this script in conjunction with "Run User Tool", so that a single user tool invocation can sequence some automated conversions and then print the result to a PDF, followed by a revert and running another similar user tool to create and print an alternate version, and so on. Each top-level user tool automatically does everything needed to create and print its specific version.
Invocation command for general use is: wscript scripts\prw_PrintToPdf.vbs "<PROMPT:Suffix:=*>"
Drop ".txt" from file name after downloading. Specify "File Text" for "Input Type". Specify "Long Task Handling" option.
How will this affect my oversize Segno and Coda target in the *Dings suites???
Hi Lawrie - Sorry, but I didn't explain myself well here either. The other glyphs I changed were mostly the articulations as I recall. And what I did was simply to get rid of extra artificial space before and/or after the glyph. The program is well designed, and generally sequences glyphs one after the other (or one above or below the other, in the case of articulation "stacks"). Font glyphs can generally be any size you want. The program just ensures minimal spacing between glyphs (which it can only do if the font is not slipping in extra articficial spacing to any side of the glyph). Again, sorry I wasn't clear on this point.
Ignoring the width in the font affects font designers who now cannot make these glyphs wider than NWC2STDA.
I'm sorry Rick, but I'm not understanding the issue. Font designers can still make these glyphs as wide as they want to. The code now sequences the glyphs one after another, with a bit of spacing (one-fourth the width of a natural glyph) in between each. The only thing I feel like I took away was the ability to pack the glyphs in extremely close together, which I thought was the original problem! Can you help me understand better? Is it perhaps just that I wasn't clear that each glyph follows right after the previous (no matter how big the previous one was)? There is no hard-coded fixed offset that the program jumps to, which would indeed have limited the size of the glyphs.
Hi Rick - I did a bit of work in this area, actually shrinking all the key signature glyphs (and others as well) to their minimum sizes, and then having the code handle all possible sequencing of sharps, flats, and accidentals in a key signature. I hope the spacing is now to your liking. - Randy
I thought I might say here how it might be implemented, in case anyone would rather see it done differently. I'd do it as a tempo variance, as you suggested. I'd look back to the last tempo before the last tempo (two tempos back), so it actually implements itself in playback, I believe, as well as displays the directive. A simple usage would be to have a Tempo A section, and then a Tempo B section, and then an "a tempo" would return to whatever tempo A was, even if tempo A were subsequently changed. A more complex usage would be to combine "a tempo" with another "true" tempo variance (i.e. something other than "a tempo", "fermata", or "break mark"):
Tempo A
...
"true" tempo variance (e.g. Ritardando)
...
Tempo B (hidden!)
"a tempo"
The hidden Tempo B gives the "true" tempo variance a "target" to shoot for, so on playback it knows how fast to slow down or speed up (and by the way, the two tempos always determine whether it slows down or speeds up, not the particular "true" tempo variance, so for example, a Ritardando can actually play back as an increase in speed!). The "a tempo" would correctly resume Tempo A in this case, after slowing down or speeding up to Tempo B.
But if there are any "manual" ties or slurs (i.e. they've been forced to upward or downward), the stem audit will not fix these I don't think. Overrides of stem lengths would also not be fixed appropriately, if needed to account for vertical shifting. I could write a quick user tool to restore all such manual overrides to their defaults, but I'm sure someone else could do it better than me. :-)
NWC does indeed continue with pure circles for circled bar numbers, apparently no matter how high the numbers get. For 4-digit bar numbers, the circle is touching the top line of the staff. For 5-digit bar numbers, the circle dips down into the staff. Of course, I doubt many pieces will make 4 digits for number of bars, let alone 5 or more (1812 is only 422 measures). I just thought that if rehearsal letters were completely opened up to the user to type in as many characters as they want to, there would have to be some point at which the circle was "rounded" out, or else some limit on the number of characters would need to be enforced, or else the program would have to handle drawing circles where part of the circle was well down into the staff below, and well up into the staff above, and even off the page/screen entirely. It can be that the user gets what he asks for, but it can't be that the program can be blown up by absurd usage.
If just the noteheads are red (i.e. the stems are still black), then select all the red notes (or all the notes for that matter, via select all), and edit properties, and change the notehead color property for notes to default. If the entire notes are red, select all the red ones, and then hit "\" (backslash) 7 times (until the color seems white, but turns black/blue when unhighlighted). You probably just hit a "\" once accidently, changing the default color (#0) to red (#1) - "\" cycles the color through 8 colors, 0 to 7 with wraparound.
