Re: The Orchestral Staff Attribute Bug
G'day bidderxyzzy,
There is a good reason that I harp on the Orchestral Staff Attribute, and that is that it's use is required in nearly every score of any complexity at all, while NoteWorthy's behavior is utterly unacceptable for any purpose whatever. It would also seem utterly trivial to fix.
I wonder if it is truly as trivial as you suggest? What impact will such a change have on the rest of the code? Just how difficult will it be to code around the dependancies? - only Eric can truly tell.
Afraid I must disagree with you here... NWC's behaviour is mostly just fine for my needs - far from "utterly unacceptable for any purpose whatever".
My main use of NoteWorthy requires that I distribute .nwc files, in which kludges, workarounds, separate visual and sounding staves and the like are unacceptable. My workaround is to print the music without using orchestral staves, print separate pages with orchestral braces of each required length on otherwise blank staves and combine them graphically using Windows Paint. This is acceptable because I scan all the music I deal with anyway, and before I do the OMR step with Sharp Eye (or when I print music my club holds copyright to (or which is public domain)), I usually need to do considerable graphical restoration (like fixing loose leaf holes punched through clefs) of this same sort.
If it is the visual representation that is paramount then what's the problem with hidden staves that do the actual work for playback?
Indeed, one of NoteWorthy's better attributes is its nearly complete bilingualism between keyboard and mouse, which is getting rarer every year. The ability to select by clicking on as well as dragging over would be completely compatible with the current usage, and Lawrie's suggested keyboard synonym for a click on a chord note is, as far as I can see, perfect.
I concur, and thankyou.
The need for such a facility is acute in my case because of the extensive editing I must to do in correcting NoteWorthy's atrocious enharmonic spelling, especially in the piano accompaniment.
Hmm, I've read complaints about this before, but haven't really experienced it. In fact, whenever the enharminic spelling has been a problem I simply make sure the key signature is correct and do a |Tools|Audit Enharmonic Spelling| - this usually fixes things quite well. 'Tis a good idea to Force Accidentals before and key sig change...
I would also like to see the requirement that all selected notes have the same duration before the duration set button (or keystroke) is activated be dropped, as it adds nothing to either function or safety, and makes the correction of the tied figures MIDI input makes of triplets more difficult.
I have found this to be a minor irritant too.
Finally, I must insist that neither "unexpectedness" nor the programmer's intent has anything to do with the definition of the term "bug" as used in the software industry. If the result is wrong, it's a bug, period.
Perhaps we need to examine in whose eyes the result is wrong... Eric has written the code. It is my understanding that the code does what he wrote it to do. To me this is an expected result - whether I like the result or not is totally irrelevant. Thus not a bug. Simply a disagreement in design preferences between people.
If he had written the program to behave as we would prefer but got this result instead then it would be a bug - and knowing Eric's responsiveness in the past, it would be quickly fixed.
While I'm almost certain I've seen it mentioned somewhere I can't remember, or don't know - amounts to the same thing - what reference(s) Eric has used in defining the design parameters. Perhaps what we are seeing actually corresponds with said reference - I can't tell you for sure 'cos I ain't seen it!
============
You seem to use SharpeEye quite a lot - PLEASE, stop using MIDI as the intermediate step and export as mxml and use mxml2nwc to import - gets rid of the enharmonic spelling and triplet problems altogether.
Try it, it works!